我们在前面介绍了 ZooKeeper 集群中的三个服务器角色：Leader、Follower 和 Observer。其中，Leader 选举是 ZooKeeper 中最重要的技术之一，也是保证分布式数据一致性的关键所在。本期内容将重点讲解 Leader 是如何被选举的。

1. Leader 的选举机制

Zookeeper 在配置文件中并没有指定 Master 和 Slave。但是，Zookeeper 工作时， 是有一个节点为 Leader，其他则为 Follower，而这个 Leader 是通过内部的选举机制临时产生的。

每个 Server 首先都提议自己是 Leader，并为自己投票，然后将投票结果与其他 Server 的选票进行对比，权重大的胜出，使用权重较大的选票更新自身的投票箱，我们介绍下服务器启动时期的 Leader 选举。

1）每一个 Server 都会发出一个投票

在集群初次启动时，每个 Server 都会推荐自己为 Leader，然后各自将这个投票发给集群中其他 Server。

2）接收来自各个 Server 的投票

每个 Server 在接收到其他 Server 的投票后，首先会判断该票的有效性，包括检查是否本轮投票，是否来自 Looking 状态的 Server。（Looking 状态表示当前集群正处于选举状态）

3）处理投票

针对每一个投票，Server 都会将别人的投票和自己的投票进行 PK，计算出 Zxid 最大的 Server，并将该 Server 设置成下一次投票推荐的 Server。

4）统计投票

每次投票结束之后，都会统计所有投票，获取投票最多的 Server 将成为获胜者，如果获胜者的票数超过集群个数的一半，则该 Server 将为推选为 Leader。否则继续投票，直至 Leader 被选举出来。

5）改变服务器状态

一旦 Leader 确定后，Leader 会通知其他 Follower 集群已经成为 Uptodate 状态，Follower 在收到 Uptodate 消息后，接收 Client 的请求并开始对外提供服务。

2. 选举 Leader 的具体实例

上述的选举过程比较抽象，我们以一个有5个节点的集群为例，目前均为 shutdown 状态。

按照 Server 的编号依次启动，看下整个的选举过程是如何实现的。

1）Server 1 启动

Server 1 启动后会提议自己为 Leader 并为自己投票，然后将投票结果发送给其他 Server，由于其他 Server 还未启动，因此收不到任何反馈信息，此时 Server 1 会处于 Looking 状态。

2）Server 2 启动

Server 2 启动后会提议自己为 Leader 并为自己投票，然后与 Server 1 交换投票结果，由于 Server 2 的编号大于 Server 1，因此 Server 2 胜出。但是，由于投票数未过集群数的一半，两个 Server 仍然均处于 Looking 状态。

3）Server 3 启动

Server 3 启动后会提议自己为 Leader 并为自己投票，然后与 Server 2、Server 3 交换投票结果，由于 Server 3 的编号最大，因此 Server 3 胜出。此时， Server 3 的票数大于集群数的一半了，因此 Server 3 会更新为 Leader ，Server 1、Server 2 更新为 Follower。

4）Server 4 启动

Server 4 启动后会提议自己为 Leader 并为自己投票，然后与 Server 1、Server 2、Server 3 交换投票结果，发现 Server 3 已经成为了 Leader，因此 Server 4 也成为了 Follower。

5）Server 5 启动

与 Server 4 一样，Server 5 启动后会给自己投票，然后与其他 Server 交换信息，发现 Server 3 已经成为了 Leader，因此 Server 5 也成为了 Follower。

（补充）

投票 vote 的数据结构

- id：服务器ID，用来唯一标识 ZooKeeper 集群中的服务器；

- Zxid：事务ID，用来唯一标识一次服务器状态的变更；

- electionEpoch：代表当前服务器的选举轮次，是一个自增序列；

- peerEpoch：被推举的 Leader 的选举轮次；

- state：当前服务器的状态。