【Zookeeper】集群模式：Leader 选举过程分析

1.选举情景

leader选举存在于两个阶段：

1. 服务器启动时的leader选举
2. 运行过程中leader节点宕机，导致要选举新leader

2.选举相关参数

几个关于选举中要使用的参数：

• 服务器ID（myid）：比如有三台服务器，编号分别为1/2/3。编号越大在选择算法中权重越大

• 事务ID（zxid）：由leader产生，被携带在Proposal中。值越大说明数据越新，权重也越大

• 逻辑时钟（epoch-logicallock）：或者叫投票次数，同一轮投票过程中逻辑时钟值是相同的。每完成一次投票这个数据就会增加，然后与接收到的其他服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断

• 选举状态：

  • LOOKONG：竞选状态
  • FOLLOWING：随从状态，同步leader状态，参与投票
  • OBSERVING：观察状态，同步leader状态，不参与投票
  • LEADING：领导者状态

  服务器启动时的 leader 选举，每个节点启动的时候状态都是 LOOKING，处于观望状态，接下来就开始进行选主流程

3.选举流程

3.1 启动时选举

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

1）发出投票

由于是初始情况，每隔Server都会发出一个投票（投自己），即Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID使用(myid, ZXID)来表示。

zxid是64位，高32位是epoch编号，每经过一次 Leader 选举产生一个新的 leader，新的 leader 会将epoch号+1；低32位是消息计数器，每接收到一 条消息这个值+1，新 leader选举后这个值重置为0。

此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

2）接收投票

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

3）处理投票

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

1. 优先比较epoch，看是否处于同一周期
2. 其次检查zxid，zxid较大的服务器优先作为leader
3. 如果zxid相同，那么就比较myid，myid较大的服务器作为leader服务器

4）重新投票

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)， 首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为(2, 0)，然后重新投票，对于 Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可

5）统计投票

每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了 Leader

6）更新状态

一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader， 就变更为LEADING。

3.2 运行时选举

当集群中的 leader 服务器出现宕机或者不可用的情况时，那么整个集群将无法对外提供服务，而是进入新一轮的 Leader 选举，服务器运行期间的Leader选举和启动时期的Leader选举基本过程是一致的。

1）变更状态（启动时没这一步）

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

2）发出投票

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

剩余步骤同启动时选举：

3）接收投票
4）处理投票
5）重新投票
6）统计投票
7）更新状态