关于java:蚂蚁面试官Zookeeper-的选举流程是怎样的我当场懵逼了

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

每次面试也只晓得个大略，并没有深究具体的流程，所以在面试的时候总是不能感动面试官，总是特地吃亏，所以这篇就总结一下其中的要点，也心愿能帮忙大家搞定面试。

有一说一， Zookeeper 这些工作原理、选举流程，兴许大多数人在工作中不会用到，但理解多一点也是本人的劣势，防止求职面试被面试官打压工资。Zookeeper 也是当初后端支流的分布式协调框架，很多热门框架都有间接或者间接依赖它，比方：Dubbo、Elastic Job、Kafka 等，所以把握 ZK 选举流程也是十分有必要的。

本文会以通俗易懂的形式进行， ZK 小白也能看懂。另外，我也将 Zookeeper 系列支流面试题和参考答案都整顿好了，关注公众号Java技术栈回复关键字 “面试” 进行刷题。

基本概念

理解选举前你得理解一些 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 票 <= 1)

所以你晓得 ZK 集群为什么至多要 3 台了吧？

3、Zookeeper 集群要 2 台及以上机器能够相互通信

只有达到 2 台服务器通信了能力进行选举，只有一台服务器启动时无奈进行选举，因为服务器之间通信了才能够相互同步投票后果。

选举流程

1、集群初始选举

Zookeeper 在集群启动时会进行选举，这里拿 3 台服务器进行举例：

顺次启动 3 台服务器 zk1, zk2, zk3，初始状况下事务 ID 都为 0。

选举大抵流程：

1、初始投票

服务器启动后，每个 Server 都会给本人投上一票，每次投票会蕴含所投票服务器的 myid 和 zxid，这里应用 Server（myid, zxid）的形式示意，此时的投票后果为：zk1（1, 0），zk2（2, 0），zk3（3, 0）

2、同步投票后果

集群中的服务器在投票后，会将各自的投票后果同步给集群中其余服务器。

3、查看投票有效性

各服务器在收到投票后会查看投票的有效性，如：是否本轮投票，是否来自 LOOKING 状态的服务器的投票等。

4、解决投票

服务器之间会进行投票比对，规定如下：

• 优先查看 zxid，较大的服务器优先作为 Leader
• 如果 zxid 雷同，则 myid 较大的服务器作为 Leader

如：zk1 和 zk2 进行比对，此时 zk2 胜出，zk1 更新本人的投票为：zk1（2, 0）

5、统计投票后果

每轮投票比对之后都会统计投票后果，确认是否有超过半数的机器都失去雷同的投票后果，如果是，则选出 Leader，否则持续投票。

本轮选举中，zk1 和 zk2 都失去了雷同的投票后果（2, 0），2 指 zk2，并且超过了半数的机器（2 > 3 / 2），所以此时 zk2 就成为了本轮选举的 Leader。

所以，即便 zk3 启动了，因为集群曾经有了 Leader，所以选举也完结了，zk3 不再参加选举，前面进来的都是小弟。

6、更改服务器状态

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

zk1 >>> FOLLOWING

zk2 >>> LEADING

Zk3 >>> FOLLOWING

2、集群从新选举

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 选举流程你看懂了吗？这只是粗略版的选举流程，理论选举过程要更简单，有趣味的能够深入研究下源码。

好了，明天的分享就到这里了，前面栈长会分享更多好玩的 Java 技术和最新的技术资讯，关注公众号Java技术栈第一工夫推送，我也将支流 Zookeeper 面试题和参考答案都整顿好了，在公众号后盾回复关键字 “面试” 进行刷题。

最初，感觉我的文章对你用播种的话，动动小手，给个在看、转发，原创不易，栈长须要你的激励。

版权申明： 本文系公众号 “Java技术栈” 原创，原创实属不易，转载、援用本文内容请注明出处，剽窃者一律举报＋投诉，并保留追究其法律责任的权力。

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2021最新版)

2.别在再满屏的 if/ else 了，试试策略模式，真香！！

3.卧槽！Java 中的 xx ≠ null 是什么新语法？

4.Spring Boot 2.5 重磅公布，光明模式太炸了！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！

喜欢 (0)赏

[搞代码]

分享 (0)