Discovery
（发现阶段
-
接受提议、生成
epoch
、接受
epoch
）
2.
Discovery（发现阶段）：在这个阶段，
followers 跟准 leader 进行通信，同步 followers
最近接收的事务提议
。这个一阶段的
主要目的是发现当前大多数节点接收的最新提议
，并且
准 leader 生成新的 epoch，让 followers 接受，更新它们的 accepted Epoch
一个 follower 只会连接一个 leader，
如果有一个节点 f 认为另一个 follower p 是 leader，f
在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入重新选举阶段
。
Synchronization
（同步阶段
-
同步
follower
副本）
3. Synchronization（同步阶段）：同步阶段主要是利用
leader 前一阶段获得的最新提议历史，
同步集群中所有的副本
。
只有当 大多数节点都同步完成，准 leader 才会成为真正的 leader
。
follower 只会接收 zxid 比自己的 lastZxid 大的提议。
Broadcast
（广播阶段
-leader
消息广播）
4. Broadcast（广播阶段）：到了这个阶段，
Zookeeper 集群才能正式对外提供事务服务，
并且 leader 可以进行消息广播
。同时如果有新的节点加入，还需要对新节点进行同步。
ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，
只需要得到超过半数的节点的 ACK 就
可以了。
ZAB
协议
JAVA
实现（
FLE-发现阶段和同步合并为 Recovery Phase（恢复阶段）
）
协议的 Java 版本实现跟上面的定义有些不同，选举阶段使用的是 Fast Leader Election（FLE），
它包含了 选举的发现职责。因为 FLE 会选举拥有最新提议历史的节点作为 leader，这样就省去了
发现最新提议的步骤。实际的实现将 发现阶段 和 同步合并为 Recovery Phase（恢复阶段）。所
以，ZAB 的实现只有三个阶段：Fast Leader Election；Recovery Phase；Broadcast Phase。
11.1.1.2. 投票机制
每个 sever 首先给自己投票
，
然后用自己的选票和其他 sever 选票对比，权重大的胜出，使用权
重较大的更新自身选票箱
。具体选举过程如下：
1.
每个 Server 启动以后
都询问其它的 Server 它要投票给谁
。对于其他 server 的询问，
server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid（系
统启动时每个 server 都会推荐自己）
2.
收到所有 Server 回复以后，就
计算出 zxid 最大的哪个 Server
，并将这个 Server 相关信
息设置成下一次要投票的 Server。
3.
计算这过程中
获得票数最多的的 sever 为获胜者
，如果获胜者的票数超过半数，则改
server 被选为 leader。否则，继续这个过程，直到 leader 被选举出来
4.
leader 就会开始等待 server 连接
5.
Follower 连接 leader，将最大的 zxid 发送给 leader
6.
Leader 根据 follower 的 zxid 确定同步点，至此选举阶段完成。
7.
选举阶段完成 Leader 同步后通知 follower 已经成为 uptodate 状态
8.
Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务了
目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5,按编号依次启动，它们
的选择举过程如下：
1.
服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反
馈信息，服务器 1 的状态一直属于 Looking。
2.
服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号
大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是
LOOKING。
3.
服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编
号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器
1,2 成为小弟。
4.
服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的
编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。
5.
服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
11.1.2. Zookeeper
工作原理（原子广播）
1.
Zookeeper 的核心是原子广播
，这个机制保证了各个 server 之间的同步。实现这个机制
的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。
2.
当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多
数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了。
3.
状态同步保证了 leader 和 server 具有相同的系统状态
4.
一
旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了
，即进
入广播状态。这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式下启动，发
现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper
服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的
followers 支持。
5.
广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号(zxid)来保
证。所有的提议(proposal)都在被提出的时候加上了 zxid。
6.
实现中 zxid 是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，
每次一个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。
7.
当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式
需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。