ZOOKEEPER的ZAB协议

ZAB协议

   ZAB（ZooKeeper Atomic Broadcast ）原子消息广播协议作为数据一致性的核心算法，ZAB协议是专为zookeeper设计的支持崩溃恢复原子消息广播算法。在深入了解ZAB，大家可以去研究了解一下paxos算法。

    协议核心如下：

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

协议介绍：

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

消息广播：

    

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

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

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

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

崩溃恢复：

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

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

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

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

  针对这个要求,如果让leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高的ZXID事务proposal，

就可以保证这个新选举出来的Leader一定具有所有已经提交的提案，也可以省去Leader服务器检查proposal的提交与丢弃的工作。

 

数据同步：

    完成了leader选举这步，在正式接受新的事务请求之前， leader服务要确认自己事务日记中的proposal是不是都已经被其他follower机器提交了，即是否完成数据同步。所有正常运行的服务器，要么成为Leader，要么成为Follower并和Leader保持同步操作。

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

a) Leader服务器会为每一Follower服务准备一个队列

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

c) 最终等到follower服务器将所有尚未同步的事务proposal都从Leader服务器上同步过来并成功应用到本地数据库后，Leader服务器才会将该Follower服务器加入到可用的Follower列表中，并开始之后的其他流程。

丢弃的事务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。