Zab也是一个强一致性算法，也是(multi-)Paxos的一种，全称是Zookeeper atomic broadcast protocol，是Zookeeper内部用到的一致性协议。相比Paxos，也易于理解。其保证了消息的全局有序和因果有序，拥有着一致性。Zab和Raft也是非常相似的，只是其中有些概念名词不一样。
Role(or Status)
节点状态：
Leading：说明当前节点为Leader
Following：说明当前节点为Follower
Election：说明节点处于选举状态。整个集群都处于选举状态中。
Epoch逻辑时钟
Epoch相当于paxos中的proposerID，Raft中的term，相当于一个国家，朝代纪元。
Quorums：
多数派，集群中超过半数的节点集合。
节点中的持久化信息：
history: a log of transaction proposals accepted; 历史提议日志文件
acceptedEpoch: the epoch number of the last NEWEPOCH message accepted; 集群中的最近最新Epoch
currentEpoch: the epoch number of the last NEWLEADER message accepted; 集群中的最近最新Leader的Epoch
lastZxid: zxid of the last proposal in the history log; 历史提议日志文件的最后一个提议的zxid
在 ZAB 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，
低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；
高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。
epoch：可以理解为当前集群所处的年代或者周期，每个 leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为 follower 只听从当前年代的 leader 的命令。
ZAB协议
Zab协议分为四个阶段
Phase 0: Leader election（选举阶段，Leader不存在）
节点在一开始都处于选举阶段，只要有一个节点得到超半数Quorums节点的票数的支持，它就可以当选prospective leader。只有到达 Phase 3 prospective leader 才会成为established leader(EL)。
这一阶段的目的是就是为了选出一个prospective leader（PL），然后进入下一个阶段。
协议并没有规定详细的选举算法，后面我们会提到实现中使用的 Fast Leader Election。
Phase 1: Discovery（发现阶段，Leader不存在）
在这个阶段，PL收集Follower发来的acceptedEpoch(或者)，并确定了PL的Epoch和Zxid最大，则会生成一个NEWEPOCH分发给Follower，Follower确认无误后返回ACK给PL。
这个一阶段的主要目的是PL生成NEWEPOCH，同时更新Followers的acceptedEpoch，并寻找最新的historylog，赋值给PL的history。
这个阶段的根本：发现最新的history log，发现最新的history log，发现最新的history log。
一个 follower 只会连接一个 leader，如果有一个节点 f 认为另一个 follower 是 leader，f 在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入 Phase 0。
1PL Followers
2|<---------X--X--X FOLLOWERINFO(F.acceptedEpoch)
3X--------->|->|->| NEWEPOCH(e′)
4|<---------X--X--X ACKEPOCH(F.currentEpoch, F.history, F.lastZxid)，接着PL寻找所有Follower和PL中最新的history赋值给PL.history
Phase 2: Synchronization（同步阶段，Leader不存在）
同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。只有当 quorum 都同步完成，PL才会成为EL。follower 只会接收 zxid 比自己的 lastZxid 大的提议。
这个一阶段的主要目的是同步PL的historylog副本。
1PL Followers
2X--------->|->|->| NEWLEADER(e′ , L.history)
3|<---------X--X--X ACKNEWLEADER(e′,L.history)
4X--------->|->|->| COMMIT message,Follow Deliver ⟨v, z⟩,PL->L
Phase 3: Broadcast（广播阶段，Leader存在）
到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。
这个一阶段的主要目的是接受请求，进行消息广播
值得注意的是，ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，只需要得到 quorum （超过半数的节点）的 ACK 就可以了。
1Client Leader Followers
2| | | | |
3 X-------->| | | | write Request
4| X--------->|->|->| sent Propose ⟨e′, ⟨v, z⟩⟩
5| |<---------X--X--X Append proposal to F.history,Send ACK(⟨e′, ⟨v, z⟩⟩) to L
6| X--------->|->|->| COMMIT(e′, ⟨v, z⟩),F Commit (deliver) transaction ⟨v, z⟩
zookeeper中zab协议的实现
协议的 Java 版本实现跟上面的定义有些不同，选举阶段使用的是 Fast Leader Election（FLE），它包含了 Phase 1 的发现职责。因为 FLE 会选举拥有最新提议历史的节点作为 leader，这样就省去了发现最新提议的步骤。实际的实现将 Phase 1 和 Phase 2 合并为 Recovery Phase（恢复阶段）。所以，ZAB 的实现只有三个阶段：
Phase 1:Fast Leader Election(快速选举阶段，Leader不存在)
前面提到 FLE 会选举拥有最新提议历史（lastZixd最大）的节点作为 leader，这样就省去了发现最新提议的步骤。这是基于拥有最新提议的节点也有最新提交记录的前提。
每个节点会同时向自己和其他节点发出投票请求，互相投票。
选举流程：
选epoch最大的
epoch相等，选 zxid 最大的
epoch和zxid都相等，选择serverID最大的（就是我们配置zoo.cfg中的myid）
节点在选举开始都默认投票给自己，当接收其他节点的选票时，会根据上面的条件更改自己的选票并重新发送选票给其他节点，当有一个节点的得票超过半数，该节点会设置自己的状态为 leading，其他节点会设置自己的状态为 following。
Phase 2:Recovery Phase（恢复阶段，Leader不存在）
这一阶段 follower 发送它们的 lastZixd 给 leader，leader 根据 lastZixd 决定如何同步数据。这里的实现跟前面 Phase 2 有所不同：Follower 收到 TRUNC 指令会中止 L.lastCommittedZxid 之后的提议，收到 DIFF 指令会接收新的提议。
1L Followers
2X----------------- L.lastZxid ← ⟨L.lastZxid.epoch + 1, 0⟩
3|<---------X--X--X FOLLOWERINFO(F.lastZxid)
4X--------->|->|->| NEWEPOCH(L.lastZxid)
5X--------->|->|->| SNAP,DIFF or TRUNC指令
6|<---------X--X--X if TRUNC notAccept L.lastZxid else(DIFF) accept,commit proposal else(SNAP) ...
Phase 3:Broadcast Election(广播阶段，Leader存在)
同上
Leader故障
如果是Leader故障，首先进行Phase 1:Fast Leader Election，然后Phase 2:Recovery Phase，恢复阶段保证了如下两个问题，这两个问题同时也和Raft中的Leader故障解决的问题是一样的，总之就是要保证Leader操作日志是最新的：
已经被处理的消息不能丢
被丢弃的消息不能再次出现
总结
Zab和Raft都是强一致性协议，但是Zab和Raft的实质是一样的，都是mutli-paxos衍生出来的强一致性算法。简单而言，他们的算法都都是先通过Leader选举，选出一个Leader，然后Leader接受到客户端的提议时，都是先写入操作日志，然后再与其他Followers同步日志，Leader再commit提议，再与其他Followers同步提议。如果Leader故障，重新走一遍选举流程，选取最新的操作日志，然后同步日志，接着继续接受客户端请求等等。过程都是一样，只不过两个的实现方式不同，描述方式不同。实现Raft的核心是Term，Zab的核心是Zxid，反正Term和Zxid都是逻辑时钟。