- ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议,实现分布式数据一致性
- 所有客户端的请求都是写入到Leader进程中,然后,由Leader同步到其他节点,称为Follower。在集群数据同步的过程中,如果出现Follower节点崩溃或者Leader进程崩溃时,都会通过Zab协议来保证数据一致性
ZAB协议的两种模式
ZAB协议包括两种基本的模式:消息广播
和崩溃恢复
消息广播:
- 集群中所有的事务请求都由Leader节点来处理,其他服务器为Follower,Leader将客户端的事务请求转换为事务Proposal,并且将Proposal分发给集群中其他所有的Follower。
- 完成广播之后,Leader等待Follwer反馈,当有过半数的Follower反馈信息后,Leader将再次向集群内Follower广播Commit信息,Commit信息就是确认将之前的Proposal提交。
- Leader节点的写入是一个两步操作,第一步是广播事务操作,第二步是广播提交操作,其中过半数指的是反馈的节点数>=N/2+1,N是全部的Follower节点数量。
崩溃恢复
- 初始化集群,刚刚启动的时候
- Leader崩溃,因为故障宕机的时候
- Leader失去了半数的机器支持,与集群中超过一半的节点断连的时候
此时开启新一轮Leader选举,选举产生的Leader会与过半的Follower进行同步,使数据一致,当与过半的机器同步完成后,就退出恢复模式,然后进入消息广播模式。
整个ZooKeeper集群的一致性保证就是在上面两个状态之前切换,当Leader服务正常时,就是正常的消息广播模式;当Leader不可用时,则进入崩溃恢复模式,崩溃恢复阶段会进行数据同步,完成以后,重新进入消息广播阶段。
Zxid
是Zab协议的一个事务编号,Zxid是一个64位的数字,其中低32位是一个简单的单调递增计数器,针对客户端每一个事务请求,计数器加1;而高32位则代表Leader周期年代的编号。
Leader周期(epoch),可以理解为当前集群所处的年代或者周期,每当有一个新的Leader选举出现时,就会从这个Leader服务器上取出其本地日志中最大事务的Zxid,并从中读取epoch值,然后加1,以此作为新的周期ID。高32位代表了每代Leader的唯一性,低32位则代表了每代Leader中事务的唯一性。
Zab节点的三种状态
- following:服从leader的命令
- leading:负责协调事务
- election/looking:选举状态
© 版权声明
本站文章由不念博客原创,未经允许严禁转载!
THE END