Zookeeper选举机制

2022-05-06 (Updated: 2024-11-05)

关于 Zookeeper 选举机制的说明

Zookeeper 选举机制

（1）Server id（或sid）：服务器ID

用来唯一标识一台 ZooKeeper 集群中的机器，每台机器不能重复，和 myid 一致。

比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大，比如初始化启动时就是根据服务器ID进行比较。

（2）Zxid：事务ID

事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。

值越大说明数据越新，在选举算法中数据越新权重越大。

（3）Epoch：逻辑时钟

也叫投票的次数，没有 Leader时同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。

（4）Server状态：选举状态

LOOKING，竞选状态。

FOLLOWING，随从状态，同步leader状态，参与投票。

OBSERVING，观察状态,同步leader状态，不参与投票。

LEADING，领导者状态。

目前是有五台服务器做 Zookeeper 集群，现在在这五台服务器中，分析 Zookeeper 选举 Leader 的过程

选举步骤：

服务器 1 启动，发起一次选举，服务器 1 投自己一票，现在情况只有服务器 1 自己 1 票，不够半数（2）以上（3 票），选举无法完成，状态保持 LOOKING
服务器 2 启动，再发起一次选举，服务器 1 和服务器 2 分别投自己并交换选票信息，此时服务器 1 发现服务器 2 的 myid 比自己大，所以把票投给服务器 2，所以现在服务器 1 票数 0 票，服务器 2 票数 2 票，依然没有超过半数（2），所以俩人都是 LOOKING 状态
服务器 3 启动，再发起一次选举，同样的经历，服务器 1 和 2 会发现 3 的 myid 比自己大，所以会把票投给 3，此时服务器 1 和 2 都是 0 票，服务器 3 是 3 票，超过了半数（2），所以出结果了，服务器 3 更改状态为 LEADING，服务器 1 和 2 状态为 FOLLOWING
服务器 4 启动，发起一次选举，此时服务器 1 2 3 都不是 LOOKING 状态，所以不会再更改选票信息，所以服务器 3 是 3 票，服务器 4 是 1 票，服务器 4 服从多数，更改选票信息为服务器 3，服务器 3 依旧是 LEADING，服务器 4 状态改为 FOLLOWING
服务器 5 启动，和 4 一样的过程，最后服务器 3 是 5 票，服务器 5 是 0 票，服务器 5 状态改为 FOLLOWING

最终结果：服务器 3 是 Leader，状态为 LEADING，其他服务器为 Follower，状态为 FOLLOWING

在 Zookeeper运行期间 Leader 和 非 Leader 各司其职，当有非 Leader 服务器宕机或加入不会影响 Leader，但是一旦 Leader 服务器挂了，那么整个 Zookeeper 集群将暂停对外服务，会触发新一轮的选举。

注意：而当一台机器进入 Leader 选举流程时，当前集群也可能会处于以下两种状态：

集群中的 Leader 还是好好的，只是这个机器突然连接不上 Leader 了，当这个机器试图发起选举时，会被告知当前 Leader 的信息，然后对于这个机器来说只是重新建立下连接，同步下状态就行
集群的 Leader 确实挂了

假设目前 Zookeeper 集群是由五台服务器组成，SID 分别是 1、2、3、4、5，ZXID 分别是 8、8、8、7、7，并且此时作为 Leader 的 server3 挂掉了

现在 1 2 4 5 开始选举

服务器	EPOCH	ZXID	SID
server1	1	8	1
server2	1	8	2
server4	1	7	4
server5	1	7	5

选举规则：

选举过程：

第一次投票，每台机器都会将票投给自己。
接着每台机器都会将自己的投票发给其他机器，比如 server1 收到了三张票，发现自己的 ZXID 和 server2 的相同，所以比较 SID，发现 server2 SID 比自己大，所以把投票更改为server2；其他机器类似，都是先比较 EPOCH，再比较 ZXID，最后比较 SID

所以 server2 就是新的 Leader