ZooKeeper 学习 （二） ZAB协议简单总结

ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子消息广播协议）的协议作为其数据一致性的核心算法。

包括两种基本的模式，分别是崩溃恢复和消息广播。

消息广播

    ZAB协议的消息广播过程使用的是一个原子广播协议，类似于一个二阶段提交过程。ZAB协议的二阶段提交过程中，移除了中断逻辑，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器。我们可以在过半的Follower服务器已经返回Ack之后就开始提交事务Proposal，而不需要等待集群中所有的Follower服务器都反馈响应。
    但此模型下，无法处理Leader服务器崩溃退出而带来的数据不一致问题。因此在ZAB协议中添加了另一个模式，即采用崩溃恢复模式来解决这个问题。
    另外，整个消息广播协议是基于具有FIFO特性的TCP协议来进行网络通信的，因此能够很容易地保证消息广播过程中消息接收与发送的顺序性。Leader服务器会为每个事物Proposal提前分配一个全局单调递增的唯一ＩＤ，即事物ＩＤ（ZXID）

崩溃恢复

    Leader服务器出现崩溃，或者说由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式。

    Leader选举算法要保证两件事：能够确保提交已经被Leader提交的事务Proposal，同时丢弃已经被跳过的事务Proposal（即丢弃其他服务器未收到的事务）。针对以上要求，如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号（即ZXID最大）的事务Proposal（重点，是所有服务器都有的最高编号），那么就可以保证这个新选举出来的Leader一定具有所有已提交的提案。更为重要的是，如果让具有最高编号事务Proposal的机器来称为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步操作了。

同步数据

1.提交已经被提交的事务Proposal   
    Leader服务器会为每一Follower服务器都准备一个队列，并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器，并在每一Proposal消息后边紧接着再发送一个Commit消息，以表示该事务已经被提交。同步完后，Follower服务器才加入到真正的可用Follower列表中。

2.处理被丢弃的事务Proposal     
    新Leader服务器会根据自己服务器上最后被提交的Proposal来和Follower服务器的Proposal进行对比，比对的结果当然是Leader会要求Follower进行一个回退操作——回退到一个确实已经被集群中过半机器提交的最新的事务Proposal。
    ZXID是一个64位的数字，低32位可以看做是一个简单的单调递增的计数器，每个客户端事务请求加1，高32位则代表了Leader周期epoch的编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上读取本地日志中最大事务的ZXID，解析出epoch的值，然后加1，作为新的epoch，并将低32位置0来开始生成新的ZXID。