Zookeeper 的选举流程是怎样的？

面试经常会遇到面试官问 Zookeeper 的选举原理，我心想，问这些有啥用吗？又不要我造火箭！

每次面试也只知道个大概，并没有深究具体的流程，所以在面试的时候总是不能打动面试官，总是特别吃亏，所以这篇就总结一下其中的要点，也希望能帮助大家搞定面试。

有一说一， Zookeeper 这些工作原理、选举流程，也许大多数人在工作中不会用到，但了解多一点也是自己的优势，避免求职面试被面试官打压工资。Zookeeper 也是现在后端主流的分布式协调框架，很多热门框架都有直接或者间接依赖它，比如：Dubbo、Elastic Job、Kafka 等，所以掌握 ZK 选举流程也是非常有必要的。

了解选举前你得了解一些 Zookeeper 的基本概念。

集群机器 ID

集群机器 ID 是指 myid，它是每一个集群机器中的编号文件，代表 ZooKeeper 集群服务器的标识，手动生成，全局全一。

事务 ID

事务 ID 是指 zxid，Zookeeper 会给每个更新请求分配一个事务 ID，它是一个 64 位的数字，由 Leader 统一进行分配，全局唯一，不断递增，在一个节点的状态信息中可以查看到最新的事务 ID 信息。

集群服务器角色

Zookeeper 集群服务器有以下 3 种角色：

1、Leader（主）

2、Follower（从，参与投票）

3、Observer（观察者，不参与投票）

集群服务器状态

Zookeeper 集群服务器有以下 4 种状态：

1、LOOKING

寻找 Leader 状态，当服务器处于该状态时，表示当前集群没有 Leader，因此会进入 Leader 选举状态。

2、FOLLOWING

跟随者状态，表示当前服务器角色是 Follower。

3、LEADING

领导者状态，表示当前服务器角色是 Leader。

4、OBSERVING

观察者状态，表示当前服务器角色是 Observer。

选举方式

Zookeeper 提供了 3 种选举方式：

LeaderElection

AuthFastLeaderElection

FastLeaderElection （最新默认）

选举场景

Zookeeper 会在以下场景进行选举：

1、Zookeeper 集群启动初始化时进行选举

2、Zookeeper 集群 Leader 失联时重新选举

选举前提条件

1、Zookeeper 服务器处于 LOOKING 竞选状态

此时说明 Zookeeper 服务器集群处于群龙无首状态，另外，观察者状态不能参与竞选投票。

2、Zookeeper 集群规模至少要 3 台机器或以上

集群规则为：2N + 1台，N > 0，即最少需要 3 台，因为 ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 ZK 节点挂得太多，只剩一半或不到一半节点能工作时，集群才会失效。

如以下分析所示：

3 个节点的 Cluster 可以挂掉 1 个节点（Leader 可以得到 2 票 > 1.5)

2 个节点的 Cluster 就不能挂掉任何 1 个节点了（Leader 可以得到 1 票 3 / 2），所以此时 zk2 就成为了本轮选举的 Leader。

所以，即使 zk3 启动了，因为集群已经有了 Leader，所以选举也结束了，zk3 不再参与选举，后面进来的都是小弟。

6、更改服务器状态

一旦选出 Leader，每个服务器就会各自更新自己的状态：

Zookeeper 集群运行期间无法和 Leader 保持正常连接时，即如果 Leader 挂了，或者 Leader 服务器故障都会进行新一轮的 Leader 选举。

这里还是拿 3 台服务器进行举例：

如果作为初始选举的 Leader zk2 挂了，集群就会暂停对外提供服务，从而进行新的 Leader 选举。

选举大致过程：

1、状态变更

既然过去的老大 Leader 不可用了，那所有的 Follower 服务器就需要从 FOLLOWING 状态变更为：LOOKING，开始新的一轮 Leader 选举。

2、开始投票

投票逻辑和启动初始时一致。

zk1, zk3 第一轮投票默认还是会先投给自己，zk2 挂了不能进行投票。

第一轮投票结果为：zk1（1, 66）、zk3（3, 28），zk1 和 zk3 各得一票，这里假设 zk1 事务 ID 比 zk3 更大一点。

3、同步投票结果

同步投票逻辑和启动初始时一致。

4、检查投票有效性

检查投票逻辑和启动初始时一致。

5、处理投票

处理投票逻辑和启动初始时一致。

此时 zk1 和 zk3 进行比对，根据规则，由于 zk1 的事务 ID 更大一点，所以 zk1 胜出，zk3 也更新自己的投票为：zk3（1, 28）

6、统计投票结果

统计投票逻辑和启动初始时一致。

本轮选举中，zk1 和 zk3 都得到了相同的投票结果 zk1，并且超过了半数的机器（2 > 3 / 2），所以此时 zk1 就成为了本轮选举的 Leader。

7、更改服务器状态

更改状态逻辑和启动初始时一致。

所以，我们可以总结下，Zookeeper 集群按 myid 从小到大依次启动初始化时，在超过半数机器的投票的情况下，谁的 myid 最大，谁就是 Leader，知道这个定律，不同的集群规模我们都可以推算出谁是 Leader。

集群初始化时：

1）集群有 3 台机器，第 2 大的 myid 所在服务器就是 Leader；

2）集群有 4 台机器，第 3 大的 myid 所在服务器就是 Leader；

3）集群有 5 台机器，第 3 大的 myid 所在服务器就是 Leader；

3）集群有 6 台机器，第 4 大的 myid 所在服务器就是 Leader；

.....

集群重新选举时，根据 myid 和 zxid 的大小共同决断，zxid 更大的优先成为 Leader。

总之，谁得到半数以上的服务器支持，谁就是老大，Zookeeper 选举流程你看懂了吗？这只是粗略版的选举流程，实际选举过程要更复杂，有兴趣的可以深入研究下源码。