Zookeeper 的 Leader 选举

Zookeeper 的 Leader 选举

Zookeeper Leader 选举概述

Leader 选举是 zookeeper 最重要的技术之一，也是保证分布式数据一致性的关键所在

当 zookeeper 集群中的一台服务器出现以下两种情况时，需要进入 Leader 选举。

1. 服务器初始化启动。
2. 服务器运行期间无法和 Leader 保持连接。

服务器启动时的 Leader 选举

若进行 Leader 选举，则至少需要两台机器，这里以3台机器组成的zookeeper集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以互相通信，每台机器都试图找到Leader，于是进入 Leader 选举过程。选举过程如下：

1. 每个Server 发出一个投票

   由于是初始状态，Server1（假设myid为1）和 Server2（myid为2）都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID，使用（myid，ZIXD）表示。此时 Server1的投票为（1,0），Server2 的投票为 （2,0），然后各自将这个投票发给集群中的其他机器。

2. 接受来自各个服务器的投票

   机器中的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票，是否来自 LOOKING 状态的服务器

3. 处理投票

   针对每一个投票，服务器都需要将别人的投票和自己的投票进行选举，选举规则如下：

   • 优先检查 ZXID，ZXID 比较大的服务器优先作为 Leader。
   • 如果ZXID 相同，那就比较 myid，myid 较大的服务器作为 Leader 服务器。

   对于 Server1来说，它自己的投票是（1,0），而受到的投票为 （2,0），所以会更新自己的投票为 （2,0），然后重新将投票发出去；而 Server2 的投票比 Server1 大，所以不需要更新自己的投票。

4. 统计投票

   每次投票后，服务器都会统计所有投票，判断是否有过半的机器接收到相同的投票信息。

   对于 Server1 和 Server 2 服务器来说，都统计出集群中有两台机器接收了 （2,0）这个投票信息。这里已经过半的服务器选举了同一个服务器作为 Leader，即认为已经选出了 Leader。

5. 改变服务器状态

   一旦确定了 Leader ，每个服务器就会更新自己的状态：更改自身的状态为 LEADING 或 FOLLOWING

服务器运行时的 Leader 选举

在 Zookeeper 集群正常运行过程中，一旦选出一个 Leader ，那么所有服务器的集群角色一般不会再发生变化。也就是说，Leader 服务器将一直作为集群的 Leader，即使集群中有非 Leader 机器挂了或是有新机器加入集群也不会影响 Leader。但是一旦 Leader 所在的机器挂了，那么整个集群将暂时无法对外提供服务，会进入新的一轮 Leader 选举。服务器运行期间的 Leader 选举和启动期选举基本过程是一致的。

假设正在运行的 zookeeper 集群为3台机器，Leader 为 Server2，假设在某个时间，Server2 挂了，这个时候便开始了 Leader 选举。

1. 变更状态

   Leader 挂后，余下的所有非 Observer 服务器都会将自己的服务器状态变更为 LOOKING，然后进入 Leader 选举过程。

2. 每个Server会发出一个投票

   在运行期间，每个服务器上的 ZXID 可能不同，假设此时 Server1 的 ZXID 为123，Server3的 ZXID 为 122；在第一轮投票中，Server1和Server3都会投自己，产生投票（1,123）和（3,122），然后将各自投票发送给集群中的其他机器；

3. 接收来自各个服务器的投票

   与启动时相同，Server3会更新自己的投票，改为投Server1

4. 处理投票

   与启动时相同，此时，Server1 将会成为Leader

5. 统计投票

6. 改变服务器状态