zookeeper选举机制

目录

前言：

一     zookeeper集群各节点内部信息 

二      当服务器第一次启动时，zookeeper选举

三      当服务器非第一次启动时（重新选举）

---

前言：

        zookeeper作为一个分布式协调服务框架，其内部的决策者的选举是必不可少的。因此本文将详细介绍zookeeper是如何进行选举的。

一     zookeeper集群各节点内部信息 

        下图是一个zookeeper集群在正常部署完毕后的结构图。接下来我们对这个模拟集群进行分析。

 

zookeeper选举所依据的信息

SID	服务器ID。 用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复， 和myid一致。
ZXID	事务ID。 ZXID是一个事务ID，用来标识一次服务器状态的变更。 在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch	每个Leader任期的代号 。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

二      当服务器第一次启动时，zookeeper选举

        当集群部署完毕，服务器第一次启动时，

（1）服务器1启 动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING； ​​​​​​​

（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING；
（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为 1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
（5）服务器5启动，判定过程与服务器四相同，于是直接就更改状态为FOLLOWING;

        于是，当集群服务第一次启动，集群的选举就这样选择完毕。

三      当服务器非第一次启动时（重新选举）

        重新选举的条件是，当zookeeper集群中的一台服务器出现一下两种情况之一时，就会开启重新选取机制。

        （1） 当服务器进行初始化启动时（即第一次选举）。

        （2）当服务器与leader无法连接，这个情况下也会出现两种情况。

第一种情况：

        集群本身就存在一个leader，只是这个节点连接不上而已。当这个节点试图去开启选举leader活动是，其他节点会对集群进行检测，如果检测出来leader后，会告知试图选举leader的服务器信息。因此，只需要这个节点在于leader重新建立连接即可，并进行状态同步。

第二种情况：

        集群中的leader确实不存在，leader机器发生故障。如上图所示，假设某一时刻leader节点server3与server5节点发生故障。因此要重新进行leader选举。下面分别为其他三个节点的信息。

剩余节点配置信息

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

简单理解：

EPOCH就是是否当过leader，且在任期间所参与的活动数目。

ZXID就是各节点处理事务的信息，当一个活动提交时，各节点处理的情况。（这个跟内部事务逻辑有关）。

SID 就是服务器ID，用于标识服务器的。

leader选举规则如下。

EPOCH大的节点直接胜出，如果EPOCH相同。则进行事务id比较 ，ZXID大的节点直接胜出。如果ZXID也相同，则比较服务器id,SID打的节点直接胜出。

因此，上面假设中，服务器2成为新的leader。