Zookeeper ZAB协议
4.2.1 ZAB协议
Zookeeper没有完全采用Paxos算法，而是使用Zookeeper Atomic Broadcast（ZAB Zookeeper原子消息广播协议）的协议作为数据一致性的核心算法。
ZAB协议专门为分布式协调服务Zookeeper设计的一种支持崩溃恢复的原子广播协议。
4.2.2 ZAB协议介绍
Zookeeper中只允许一个Leader服务器进行事务的处理。非Leader服务器会将收到的客户端事务请求转发给Leader。
两种基本的模式
- 消息广播
针对客户端事务请求，Leader服务器生成对应的Proposal，并将其发送给集群中其余所有机器，收集到半数Follower的ACK后开始提交事务Proposal。
在二阶段提交时，Leader崩溃退出回来带数据不一致问题，所以需要以下崩溃恢复模式。
整个消息广播基于FIFO特性的TCP协议进行网络通信的，因此很容易保证消息广播过程中消息接收与发送的顺序性
Leader会为事务Proposal分配一个全局单调递增的唯一ID（事务ID ，ZXID）。ZAB协议需要保证每一个消息严格的因果关系，因此必须按照ZXID的先后顺序进行排序处理。
Leader服务器会为每个Follower服务器分配一个单独队列，让后将事务Proposal依次放入队列，根据FIFO策略发送消息。 - 崩溃恢复
出现Leader崩溃或者网络原因Leader时区了过半Follower的联系，就会进入崩溃恢复模式。需要快速选举新的Leader，让自己及其他机器感知新Leader服务器。
ZAB协议需要确保那些已经在Leader服务器上提交的事务会被所有服务器提交，而只在Leader上提出的事务需要被丢弃。针对这个要求，如果让Leader选举算法能够保证选举的new Leader有集群中所有机器最大ZXID的事务Proposal，就可以保证new leader一定具有所有已经提交的提案。更重要的是，有最大ZXID的机器称为Leader，可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步骤。
数据同步
完成Leader选举后，正式开始工作前，Leader服务器先确认事务日志中的所有Proposal都已被集群过半及其提交，即是否返程数据同步。
所有正常服务器，要么称为Leader，要么称为Follower并同步Leader。Leader为每个Follower准备一个队列，并将没有被Follower同步的事务以Proposal消息形式发送给Follower服务器，并在每个Proposal消息后紧接着发送一个Commit消息，以表示该事务已被提交。等到Follower将Leader服务器所有事务Proposal成功同步到本地数据库，Leader服务器将F欧力威服务器加到真正的可用Follower列表中，并开始之后的其他流程。
ZXID是一个64位的数字，低32位可以看作单调递增计算器，每个事务Proposal都会对该计数器加1。高32位则代表Leader周期epoch的编号，每选举产生一个新的Leader服务器，就会在原ZXID的epoch基础上加1，以此作为新的epoch，并将低32位置0开始生成新ZXID。
ZAB写通过epoch编号区分Leader周期变化，有效避免了不同Leader服务器错误使用相同的ZXID编号提出不一样的事务Proposal的异常情况，对于识别Leader崩溃恢复前后产生的Proposal非常有帮助，简化和提升了数据恢复流程。
4.2.3 深入ZAB协议
细分三个阶段：发现，同步，广播，
4.2.4 ZAB与Paxos算法的联系与区别
联系：
- 都存在Leader
- Leader需要得到半数Follower的投票才能提交Proposal
- Leader周期标识 ZAB协议的epoch ，Paxos中的Ballot
区别
Paxos中，新选举的主进程进行两阶段的工作。第一阶段，读阶段，在这个阶段中，new leader会和所有其他进程通信收集上一个主进程的提案，并将他们提交。第二阶段，写阶段，这个阶段，当前主进程开始提出自己的天。
ZAB协议额外添加了一个同步阶段。同步阶段之前，ZAB协议也存在一个和Paxos算法的读阶段类似的过程，发现（discovery）阶段。在同步阶段中，新的Leader会确保存在过半Follower已经提交了之前Leader周期中的所有格事务Proposal。同步阶段的引入，有效保证Leader在新的周期中提出事务Proposal前，所有进程已完成对之前所有事务Proposal的提交。同步阶段完成后，ZAB就会执行和Paxos算法类似的写阶段。
