ZooKeeper系统模型之Leader选举算法分析。

缺乏、安全感 2024-02-18 18:22 46阅读 0赞

在ZooKeeper中，提供了三种Leader选举的算法，分别是LeaderElection、UDP版本的FastLeaderElection和TCP版本的FastLeaderElection，可以通过在配置文件zoo.cfg中使用electionAlg属性来指定，分别使用数字0~3来表示。0代表LeaderElection，这是一种纯UDP实现的Leader选举算法：1代表UDP版本的FastLeaderElection，并且是非授权模式；2也代表UDP版本的FastLeaderElection，但使用授权模式；3代表TCP版本的FastLeaderElection。值得一提的是，从3.4.0版本开始，ZooKeeper废弃了0、1、2这三种Leader选举算法，只保留了TCP版本的FastLeaderElection选举算法。下文即仅对此算法进行介绍。

## 术语解释 ##

*  **SID：服务器ID**

> SID是一个数字，用来标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid的值一致。

*  **ZXID：事务ID**

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

*  **Vote：投票**

> Leader选举，顾名思义必须通过投票来实现。当集群中的机器发现自己无法检测到Leader机器的时候，就会开始尝试进行投票。

*  **Quorum：过半机器数**

> 这是整个Leader选举算法中最重要的一个术语，我们可以把这个术语理解为是一个量词，指的是ZooKeeper集群中过半的机器数，如果集群中总的机器数是n的话，那么可以通过下面这个公式来计算quorum的值：
> 
> quorum = (n/2 + 1)
> 
> 例如，如果集群机器总数是3，那么quorum就是2。

## 算法分析 ##

### 进入Leader选举 ###

当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举。

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

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

*  集群中本来就已经存在一个Leader。
 *  集群中确实不存在Leader。

我们首先来看第一种已经存在Leader的情况。这种情况通常是集群中的某一台机器启动比较晚，在他启动之前，集群已经可以正常工作，即已经存在了一台Leader服务器。针对这种情况，当该机器试图去选举Leader的时候，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。

下面我们重点来看在集群中Leader不存在的情况下，如何进行Leader选举。

#### 开始第一次投票 ####

通常有两种情况会导致集群中不存在Leader，一种情况是在整个服务器刚刚初始化启动时，此时尚未产生一台Leader服务器；另一种情况就是在运行期间当前Leader所在的服务器挂了。无论是哪种情况，此时集群中的所有机器都处于一种试图选举出一个Leader状态，我们把这种状态称为“LOOKING”，意思是说正在寻找Leader。当一台服务器处于LOOKING状态的时候，那么他就会向集群中所有其他机器发送消息，我们称这个消息为“投票”。

在这个投票消息中包含了两个最基本的信息：所推举的服务器的SID和ZXID，分别表示了被推举服务器的唯一标识和事务ID。下文中我们将以“(SID, ZXID)”这样的形式来标识一次投票信息。举例来说，如果当前服务器要推举SID为1、ZXID为8的服务器成为Leader，那么他的这次投票信息可以表示为(1, 9)。

我们假设ZooKeeper由5台机器组成，SID分别为1、2、3、4和5，ZXID分别为9、9、9、8和8，并且此时SID为2的机器是Leader服务器。某一时刻，1和2所在的机器出现故障，因此集群开始进行Leader选举。

在第一次投票的时候，由于还无法检测到集群中其他机器的状态信息，因此每台机器都是将自己作为被推举的对象来进行投票。于是SID为3、4和5的机器，投票情况分别为：(3, 9)、 (4, 8)和(5, 8)。

#### 变更投票 ####

集群中的每台机器发出自己的投票后，也会接收到来自集群中其他机器的投票。每台机器都会根据一定的规则，来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票。这个规则也成为了整个Leader选举算法的核心所在。为了便于描述，我们首先定义一些术语。

*  vote\_sid：接收到的投票中所推举Leader服务器的SID。
 *  vote\_zxid：接收到的投票中所推举Leader服务器的ZXID。
 *  self\_sid：当前服务器自己的SID。
 *  self\_zxid：当前服务器自己的ZXID。

每次对于收到的投票的处理，都是一个对（vote\_sid, vote\_zxid）和（self\_sid, self\_zxid）对比的过程。

*  规则1：如果vote\_zxid大于self\_zxid，就认可当前收到的投票，并再次将该投票发送出去。
 *  规则2：如果vote\_zxid小于self\_zxid，那么就坚持自己的投票，不做任何变更。
 *  规则3：如果vote\_zxid等于self\_zxid，那么就对比两者的SID。如果vote\_sid大于self\_sid，那么就认可当前接收到的投票，并再次将该投票发送出去。
 *  规则4：如果vote\_zxid等于self\_zxid，并且vote\_sid小于self\_sid，那么同样坚持自己的投票，不做变更。

根据上面这个规则，我们结合下图来分析上面提到的5台机器组成的ZooKeeper集群的投票变更过程。

> ![20180228133316734][]

每台机器都把投票发出后，同时也会接收到来自另外两台机器的投票。

*  对于Server3来说，他接收到了(4, 8) 和 (5, 8)两个投票，对比后，由于自己的ZXID要大于接收到的两个投票，因此不需要做任何变更。
 *  对于Server4来说，他接收到了(3, 9) 和 (5, 8)两个投票，对比后，由于(3, 9) 这个投票的ZXID大于自己，因此需要变更投票为(3, 9)，然后继续将这个投票发送给另外两台机器。
 *  同样，对于Server5来说，他接收到了(3, 9) 和 (4, 9)两个投票，对比后，由于(3, 9)这个投票的ZXID大于自己，因此需要变更投票为(3, 9)，然后继续将这个投票发送给另外两台机器。

#### 确定Leader ####

经过这第二次投票后，集群中的每台机器都会再次受到其他机器的投票，然后开始统计投票，如果一台机器收到了超过半数的相同的投票，那么这个投票对应的SID机器即为Leader。

如上图所示的Leader选举例子中，因为ZooKeeper集群的总机器数为5台，那么

> quorum = (5/2 + 1) = 3

也就是说，只要收到3个或3个以上（含当前服务器自身在内）一致的投票即可。在这里，Server3、Server4和Server5都投票(3, 9)，因此确定了Server3为Leader。

## 小结 ##

简单的说，通常哪台服务器上的数据越新，那么越有可能成为Leader，原因很简单，数据越新，那么他的ZXID也就越大，也就越能够保证数据的恢复。当然，如果集群中有几个服务器具有相同的ZXID，那么SID较大的那台服务器成为Leader。

[20180228133316734]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7708d58285524b2093f1c3c511ab375d.png