前一篇文章说到了 Zookeeper 基本介绍及其工作原理，本文将详解 Zookeeper 运行中的 ZAB 协议及其选主流程。关注我的公众号「Java面典」，每天 10：24 和你一起了解更多 Java 相关知识点。
ZAB 协议
事务编号 Zxid（事务请求计数器 + epoch）
在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议） 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的 Zxid，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。
Zxid（Transaction id）类似于 RDBMS 中的事务 ID，用于标识一次更新操作的 Proposal（提议）
ID。为了保证顺序性，该 Zkid 必须单调递增。
epoch
epoch：可以理解为当前集群所处的年代或者周期，每个 Leader 就像皇帝，都有自己的年号，所以每次改朝换代，Leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 Leader 崩溃恢复之后，也没有人听他的了，因为 Follower 只听从当前年代的 Leader 的命令。
Zab 协议有两种模式-恢复模式（选主）、广播模式（同步）
Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多数 Server 完成了和 Leader 的状态同步以后，恢复模式就结束了。状态同步保证了 Leader 和 Server 具有相同的系统状态。
ZAB 协议 4 阶段
Leader election（选举阶段）
选出准 Leader：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 Leader。只有到达 广播阶段（broadcast） 准 Leader 才会成为真正的 Leader。这一阶段的目的是就是为了选出一个准 Leader，然后进入下一个阶段。
Discovery（发现阶段）
接受提议、生成 epoch、接受 epoch： 在这个阶段，Follower 跟准 Leader 进行通信，同步 Follower 最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准 Leader 生成新的 epoch，让 Follower 接受，更新它们的 accepted Epoch， 一个 Follower 只会连接一个 Leader，如果有一个节点 f 认为另一个 Follower p 是 Leader，f 在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入重新选举阶段。
Synchronization（同步阶段）
同步 Follower 副本：同步阶段主要是利用 Leader 前一阶段获得的最新提议历史，同步集群中所有的副本。只有当 大多数节点都同步完成，准 Leader 才会成为真正的 Leader。Follower 只会接收 Zxid 比自己的 lastZxid 大的提议。
Broadcast（广播阶段）
Leader 消息广播:到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 Leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。ZAB 提交事务并不像 2PC 一样需要全部 Follower 都 ACK，只需要得到超过半数的节点的 ACK 就可以了。
ZAB 协议 JAVA 实现
FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段）
ZAB 协议的 Java 版本实现跟上面的定义有些不同，选举阶段使用的是 Fast Leader Election（FLE），它包含了选举的发现职责。因为 FLE 会选举拥有最新提议历史的节点作为 Leader，这样就省去了发现最新提议的步骤。实际的实现将 发现阶段 和 同步合并为 Recovery Phase（恢复阶段）。所以，ZAB 的实现只有三个阶段：Fast Leader Election；Recovery Phase；Broadcast Phase。
Leader 选举流程
每个 Sever 首先给自己投票，然后用自己的选票和其他 Sever 选票对比，权重大的胜出，使用权重较大的更新自身选票箱。具体选举过程如下：
- 每个 Server 启动以后都询问其它的 Server 它要投票给谁。对于其他 Server 的询问，Server 每次根据自己的状态都回复自己推荐的 Leader 的 id 和上一次处理事务的 Zxid（系统启动时每个 Server 都会推荐自己）；
- 收到所有 Server 回复以后，就计算出 Zxid 最大的那个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server；
- 计算这过程中获得票数最多的的 Sever 为获胜者，如果获胜者的票数超过半数，则改Server 被选为 Leader。否则，继续这个过程，直到 Leader 被选举出来；
- Leader 就会开始等待 Server 连接；
- Follower 连接 Leader，将最大的 Zxid 发送给 Leader；
- Leader 根据 Follower 的 Zxid 确定同步点，至此选举阶段完成；
- 选举阶段完成 Leader 同步后通知 Follower 已经成为 uptodate 状态；
- Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务了。
目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5 按编号依次启动，它们的选择举过程如下：
- 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking；
- 服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 Looking；
- 服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器1,2 成为小弟；
- 服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟；
- 服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
