一篇文章搞懂 ZooKeeper 的选举机制

前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

选举机制的简介

ZooKeeper 为了保证各节点的协同工作，在工作时需要一个 Leader 角色，而 ZooKeeper 默认采用 FastLeaderElection 算法，且投票数大于半数则胜出的机制。

在介绍选举机制前，首先了解选举涉及的相关概念。

服务器 ID

这是在配置集群时设置的 myid 参数文件，且参数分别表示为服务器 1 、服务器 2 和服务器 3 ，编号越大在 FastLeaderElection 算法中的权重越大。

选举状态

在选举过程中， ZooKeeper 服务器有 4 种状态，它们分别为

1. 竞选状态( LOOKING )
2. 随从状态( FOLLOWING ，同步 leader 状态，参与投票 )
3. 观察状态( OBSERVING ，同步 leader 状态，不参与投票 )
4. 领导者状态( LEADING )。

数据 ID

这是服务器中存放的最新数据版本号，该值越大说明数据越新，在选举过程中数据越新权重越大。

逻辑时钟

通俗地讲，逻辑时钟被称为投票次数，同一轮投票过程中的逻辑时钟值是相同的，逻辑时钟起始值为 0 ，每投完一次票，这个数据就会增加。

然后，与接收到其他服务器返回的投票信息中的数值相比较，根据不同的值做出不同的判断。

如果某台机器宕机，那么这台机器不会参与投票，因此逻辑时钟也会比其他的低。

选举机制的类型

ZooKeeper 选举机制有两种类型，分别为全新集群选举和非全新集群选举，下面分别对两种类型进行详细讲解。

全新集群选举

全新集群选举是新搭建起来的，没有数据 1D 和逻辑时钟来影响集群的选举。
假设，目前有 5 台服务器，它们的编号分别是 1 ~ 5 ，按编号依次启动 ZooKeeper 服务。

全新集群选举的过程

1. 服务器 1 启动，首先，会给自己投票;其次，发投票信息，由于其他机器还没有启动所以它无法接收到投票的反馈信息，因此服务器 1 的状态一直属于 LOOKING 状态。
2. 服务器 2 启动，首先，会给自己投票;其次，在集群中启动 ZooKeeper 服务的机器发起投票对比，这时它会与服务器 1 交换结果，由于服务器 2 的编号大，所以服务器 2 胜出，此时服务器 1 会将票投给服务器 2 ，但此时服务器 2 的投票数并没有大于集群半数( 25 / 2 )，所以两个服务器的状态依然是 LOOKING 状态。
3. 服务器 3 启动，首先，会给自己投票;其次，与之前启动的服务器 1 和服务器 2 交换信息，由于服务器 3 的编号最大所以服务器 3 胜出，那么服务器 1 和 2 会将票投给服务器 3 ，此时投票数正好大于半数( 3 > 5 / 2 )，所以服务器 3 成为领导者状态，服务器 1 和 2 成为追随者状态。
4. 服务器 4 启动，首先，给自己投票;其次，与之前启动的服务器 1 、 2 和 3 交换信息，尽管服务器 4 的编号大，但是服务器 3 已经胜出。 所以服务器 4 只能成为追随者状态。
5. 服务器 5 启动，同服务器 4 一样，均成为追随者状态。

非全新集群选举

对于正常运行的 ZooKeeper 集群，一且中途有服务器宕机，则需要重新选举时，选举的过程中就需要引入服务器 ID 、数据 ID 和逻辑时钟。

这是由于 ZooKeeper 集群已经运行过段时间，那么服务器中就会存在运行的数据。

非全新集群选举的过程

1. 首先，统计逻辑时钟是否相同，逻辑时钟小，则说明途中可能存在宕机问题，因此数据不完整,那么该选举结果被忽略,重新投票选举;
2. 其次,统一逻辑时钟后,对比数据ID值,数据ID反应数据的新旧程度,因此数据ID大的胜出;
3. 如果逻辑时钟和数据ID都相同的情况下,那么比较服务器ID(编号),值大则胜出;
   简单地讲,非全新集群选举时是优中选优,保证 Leader 是 ZooKeeper 集群中数据最完整、最可靠的一台服务器。