Zookeeper的Zab协议

在深入了解ZAB,大家可以去研究了解一下paxos算法:

  http://www.cnblogs.com/woshiweige/p/4521165.html

  https://yq.aliyun.com/articles/71213?spm=5176.100239.blogcont46994.16.tM0FKQ

  本章的书籍内容主要参考《从Paxos到Zookeeper分布式一致性原理与实践》书籍

ZAB协议

     ZAB(ZooKeeper Atomic Broadcast )原子消息广播协议作为数据一致性的核心算法,ZAB协议是专为zookeeper设计的支持崩溃恢复原子消息广播算法。

     协议核心如下:

        所有的事务请求必须一个全局唯一的服务器(leader)来协调处理,集群其余的服务器称为follower服务器。leader服务器负责将一个客户端请求转化为事务提议(Proposal),并将该proposal分发给集群所有的follower服务器。之后leader服务器需要等待所有的follower服务器的反馈,一旦超过了半数的follower服务器进行了正确反馈后,那么leader服务器就会再次向所有的follower服务器分发commit消息,要求其将前一个proposal进行提交。

 

协议介绍:

    ZAB协议的两个基本模式:消息广播和崩溃恢复

消息广播:

  blob.png

      ZAB协议的消息广播过程使用是一个原子广播协议,类似一个2PC提交过程, 具体的:ZooKeeper使用单一主进程Leader用于处理客户端所有事务请求,并采用ZAB的原子广播协议,将服务器数据状态变更以事务Proposal的形式广播Follower上,因此能很好的处理客户端的大量并发请求,(理解就是ZK通过使用TCP协议及一个事务ID来实现事务的全序特性,leader模式就是先到先执行解决因果顺序[FIFO]); 另一方面,由于事务间可能存在着依赖关系,ZAB协议保证Leader广播的变更序列被顺序的处理,有些状态的变更必须依赖于比它早生成的那些状态变更;最后,考虑到住进程leader在任何时候可能崩溃或者异常退出, 因此ZAB协议还要Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性;Follower收到proposal后,写到磁盘,返回ACK。Leader收到大多数ACK后,广播COMMIT消息,自己也提交该消息。Follower收到COMMIT之后,提交该消息。

    ZAB协议简化了2PC事务提交:

        1、去除中断逻辑移除,follower要么ack,要么抛弃Leader;

        2、leader不需要所有的Follower都响应成功,只要一个多数派ACK即可。

  1.崩溃恢复:

     上面我们讲了ZAB协议在正常情况下的消息广播过程,那么一旦leader服务器出现崩溃或者与过半的follower服务器失去联系,就进入崩溃恢复模式。

崩溃恢复过程中,为了保证数据一致性需要处理特殊情况:

      1、已经被leader提交的proposal确保最终被所有的服务器follower提交

      2、确保那些只在leader被提出的proposal 被丢弃。

      针对这个要求,如果让leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高的ZXID事务proposal,就可以保证这个新选举出来的Leader一定具有所有已经提交的提案,也可以省去Leader服务器检查proposal的提交与丢弃的工作。

   2 .数据同步:

        完成了leader选举这步,在正式接受新的事务请求之前, leader服务要确认自己事务日记中的proposal是不是都已经被其他follower机器提交了,即是否完成数据同步。所有正常运行的服务器,要么成为Leader,要么成为Follower并和Leader保持同步操作。Leader服务器需要确保所有的Follower服务器能够接收到每一条事务Proposal,并且能够正确的将所有已经提交了的事务Proposal应用到内存数据库中。

正常的数据同步的逻辑过程:

  1. Leader服务器会为每一Follower服务准备一个队列

  2. 将没有被各follower机器同步的事务以proposal消息形式,有队列发送出去,并携带Commit消息,来表示事务已经被提交。

  3. 最终等到follower服务器将所有尚未同步的事务proposal都从Leader服务器上同步过来并成功应用到本地数据库后,

    Leader服务器才会将该Follower服务器加入到可用的Follower列表中,并开始之后的其他流程。

   3.丢弃的事务proposal处理过程:

         ZAB协议中使用ZXID作为事务编号,ZXID为64位数字,低32位为一个递增的计数器,每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1,高32位为Leader周期epoch编号,当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch,将低32位从0开始生成新的ZXID;ZAB使用epoch来区分不同的Leader周期,能有效避免了不同的leader服务器错误的使用相同的ZXID编号提出不同的事务proposal的异常情况,大大简化了提升了数据恢复流程;所以这个崩溃的机器启动时,也无法成为新一轮的Leader,因为当前集群中的机器一定包含了更高的epoch的事务proposal。

 


资料: 个人CSDN :  http://blog.csdn.net/tang06211015/article/details/51843140

发表评论