概述
- ZAB(Zookeeper Atomic Broadcast)协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议
- 这套协议基于2PC算法进行的改进,又引入了PAXOS算法
- ZAB协议包括两种基本的模式,分别是:
a. 消息原子广播(保证数据一致性)
b. 崩溃恢复(解决2pc算法的单点问题)
原子广播
- 实现Zookeeper所有的节点的信息共享,保证分布式数据一致性
- 原子广播基于2PC算法进行的改进,不同的是它引入了过半性思想
(2PC算法链接:https://mp.youkuaiyun.com/mdeditor/93787728) - 原子广播的核心思想是过半 - 少数服从多数
- 原子广播无法处理Leader服务器崩溃退出而带来的数据不一致问题的,因此在ZAB协议中添加了另一个模式,即采用崩溃恢复模式来解决这个问题
原子广播流程
- leader服务器接收到事务请求,会先将该事务写到本地的log文件中
- leader服务器会为这次请求生成对应的事务Proposal并且为这个事务Proposal分配一个全局递增的唯一的事务ID,即Zxid。之后将Proposal放到队列中发给所有的follower
- 每一个follower在收到队列之后,会从队列中依次取出事务Proposal,写道本地的事务日志中。如果写成功了,则给leader返回一个ACK消息,如果失败了,向leader返回失败信号
- 当leader服务器接收到半数的follower的ACK响应之后,就会广播一个Commit消息给所有的follower以通知其进行事务提交,同时leader自身也进行事务提交。若没有收到半数的ack信号,则通知所有的follower执行回滚操作
崩溃恢复(解决单点故障问题,引入了PAXOS算法)
基于PAXOS算法进行设计的:在集群中,需要选举一个leader,各个节点之间通过网络进行消息传递。在集群中,每一个节点都可能会丢失,网络也可能会产生波动。在这种不可靠状态下,如何有效的选举出leader,这就是Paxos要做的事儿
1.当leader服务器出现崩溃、重启等场景,或者因为网络问题导致过半的follower不能与leader服务器保持正常通信的时候,Zookeeper集群就会进入崩溃恢复模式
2.进入崩溃恢复模式后,只要集群中存在过半的服务器能够彼此正常通信,那么就可以选举产生一个新的leader
3.每选举一个新的leader,都会分配一个全局递增的编号 - epochid,新leader上任之后,将当前epochid分发给每一个follower,follower收到epochid之后,将编号写到acceptedEpoch文件中,然后再更新到currentEpoch文件
4.之后当一台同样遵守ZAB协议的服务器启动后加入到集群中时,如果此时集群中已经存在一个Leader服务器在负责进行消息广播,那么新加入的服务器就会自觉地进入数据恢复模式:找到leader所在的服务器,并与其进行数据同步,然后一起参与到消息广播流程中