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