Zookeeper学习之Leader选举

待我称王封你为后i 2024-04-18 22:08 5阅读 0赞

首先介绍一下涉及选举的几个基本概念：

# 一、基本概念 #

## 1、myid（sid）：服务器ID ##

此值是在在配置集群中myid文件中的数值，同时此数值与配置文件中server. 后面数字一致。此字段代表集群中每一个ZK的代表，此数值大小也会影响投票选举，此值越大，越容易选中leader。

## 2、Zxid：数据ID ##

可以理解为版本号，或者修改次数，此值越大，代表数据越新。数据越新，就越容易选中为leader。

## 3、electionEpoch（逻辑时钟） ##

或者叫投票的次数，**同一轮投票过程中**的值是相同的。每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次。

假如**serverA**向**serverB**发送自己的投票进行投票PK，如果**serverB**收到的通知中的electionEpoch比自己的大，则**serverB**更新自己的electionEpoch为**serverA**的electionEpoch如果该**serverB**收到的通知中的electionEpoch比自己的小，则**serverB**向**serverA**发送一个通知，将**serverB**自己的投票以及electionEpoch发送给**serverA**，**serverA**收到后就会更新自己的electionEpoch。直至在electionEpoch达成一致后，才开始进行投票之间的pk。

## 4、peerEpoch（选举时代） ##

每次leader**选举完成**之后，都会选举出一个新的peerEpoch，用来标记事务请求所属的轮次。

选举出一个新的peerEpoch，主要用于防止**旧的leader**来进行提交操作（旧leader向follower发送命令的时候，follower发现zxid所在的peerEpoch比现在的小，则直接拒绝，防止出现不一致性）

## 5、选举状态 ##

>  *  LOOKING：观察状态，或者成为竞选状态。
>  *  FOLLOWING：随从状态，同步leader状态，参与投票。
>  *  OBSERVING：观察状态，同步leader状态，不参与投票。
>  *  LEADING：领导者状态。

## 6、vote（投票） ##

投票中包含如下数据：

>  *  id：这次投票投的服务器SID
>  *  ZXID：这次投票投的服务器ZXID
>  *  electionEpoch：这次投票投的服务器的选举次数
>  *  peerEpoch：当前选举的时代。
>  *  state：服务器选举状态。

# 二、选举流程 #

选举可能发生的时间：

1.  服务器集群初始化启动
2.  leader服务器挂掉

所以针对不同的情况，我们先来分情况梳理流程

## 1、服务器集群启动时期的Leader选举 ##

首选假设有三台服务器：server1、server2、server3

三台服务器情况下必须有两台启动集群才能成功启动，所以当serverA启动成功后，serverB也成功启动，此时两台服务器成功建立通讯，由于状态都是LOOKING，所以开始进入投票选举阶段：

> 1、首先两台服务器开始发起一个投票，由于是第一次投票，所以两台服务器都只会**投给自己**，这时的选票中包含着自身服务器信息的vote，我们简单的理解vote为（myid，ZXID），所以server1的投票为（1,0），server2的投票为（2，0），然后服务器将vote发送给集群中的服务器。
> 
> 2、服务器接收到其他服务器的投票，开始通过vote数据来判断是否有效，例如state是否为LOOKING，判断逻辑时钟是否一致（逻辑时钟小的选举结果被忽略，重新投票）
> 
> 3、处理投票，服务器开始将其他服务器的投票与自身服务器投票对比：
> 
>       首先判断ZXID，ZXID越大，代表数据越新，代表越能成为leader。
> 
>       ZXID一致情况下来判断MYID，MYID越大，就越能成为Leader
> 
>       对比结束之后，将自己修改后的投票发送给其余服务器
> 
> 4、每次投票后，服务器都会对其余服务器的投票结果进行分析，如果已经有过半的服务器已经接受了相同的投票信息，则任务已经选出了leader，同时修改自身状态。

**注：一旦选出leader，然后集群中又加入新的zk，将自动接收结果，不重新进行选举。**

## 2、服务器运行时期的Leader选举（原leader挂了） ##

假设条件不变，同时当前环境中已经有三台服务器都已经启动，这时，server1作为leader，由于意外，下线了。

> 1、一旦leader下线，整个集群中每个zk都将将状态修改为LOOKING，进行选举投票，同时暂停服务，开始只读模式。
> 
> 2、每个zk开始都会将投票投给自己，剩余逻辑与服务器启动时**逻辑一致**。

# 总结 #

总体来说，无论是何种情况下开始进行投票，每台zk都会将服务器投给自己，然后再进行投票处理，在投票选举中，数据越新（ZXID越大），SID越大，成为Leader的可能性就越大。当选举投票结束，选出leader后，再进入集群的ZK会直接接受投票结果，将自身状态变更为follower或者observer。

同时有投票选举机制的存在，在CAP原则里面，ZK我感觉是偏向CP的，因为一旦leader下线，整个集群将会进入暂停服务，同时如果集群数量过大，选举时间将会很长，虽然说保证了数据一致性，但是难免牺牲了可用性。（当然observer的存在也缓解了这一现象）