zookeeper Leader选举 投票过程

转载来源：https://blog.csdn.net/weixin_40849725/article/details/105783272

术语解释

• SID: 服务器ID
  SID是一个数字，用来唯一标识一台Zookeeper集群中的机器，每台机器不能重复，和myid的值一致。在每台ZooKeeper机器上，都需要在数据目录（即dataDir参数指定的那个目录）下创建一个myid文件，该文件中只有一行内容，并且只是一个数字，即对应于每台机器的ServerID数字。
• ZXID：事务ID
  ZXID是一个事务ID，用来唯一标识一次服务器状态的变更。在某一个时刻，集群中每台服务器的ZXID值不一定全都一致，这和Zookeeper服务器对于客户端“更新请求”的处理逻辑有关。
• Vote：投票
  Leader选举，顾名思义必须通过投票来实现。当集群中的机器发现自己无法检测到Leader机器的时候，就会开始尝试进行投票。
• Quorum：过半机器数
  这是整个Leader算法选举中最重要的一个术语，我们可以把这个术语理解为是一个量词，指的是Zookeeper集群中过半的机器数，如果集群中总的机器数是n的话，那么就可以通过公式得到quorum的值：quorum = ( n/2 + 1)，例如，如果集群机器总数是3，那么quorum就是2。

Zookeeper集群中的三种服务器角色

Leader、Follower、Observer
Zookeeper集群中的所有机器通过一个Leader选举过程来选定一台被称为"Leader"的机器，Leader服务器为客户端提供读和写服务。
除leader外，其他机器包括Follower和Observer。follower和observer都能提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此observer可以在不影响写性能的情况下提升集群的读性能。

Leader选举概述

一、服务器启动时期的Leader选举

在讲解Leader选举的时候，需要注意的一点事，隐士条件便是Zookeeper的集群规模至少是2台机器，这里我们以三台机器组成的服务器集群为例。在服务器集群初始化阶段，当有一台服务器（我们假设这台服务器的myid为1，因此称其为Server1）启动的时候，是无法完成、进行leader选举的。当第二台机器（同样，我们假设这台服务器的myid为2，称其为Server2）也启动后，此时这两台机器已经能进行互相通信，每台机器都试图找到一个Leader，于是便进入了Leader选举流程。

1.每个Server会发出一个投票

由于是初始情况，因此对于Server1和Server2来说，都会将自己作为Leader服务器来进行投票，每次投票包含的最基本元素包括：所推举的服务器的myid和ZXID，我们以（myid， ZXID）的形式来表示。因为是初始化阶段，因此无论是Server1还是Server2，都会投给自己，即Server1的投票为（1，0），Server2的投票为（2，0），然后各自将这个投票发给集群中其他所有机器。

2.接收来自各个服务器的投票

每个服务器都会接收来自其他服务器的投票。集群中的每个服务器在接收到投票后，首先会判断该投票的有效性，包括检查是否是本轮投票、是否来自LOOKING状态的服务器。

3.处理投票

在接收到来自其他服务器的投票后，针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK的规则如下。

• 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
• 如果ZXID相同的话，那么就比较myid。myid比较大的服务器作为Leader服务器。

现在我们来看Server1和Server2实际是如何进行投票处理的。对于Server1来说，它自己的投票是（1，0），而接收到的投票为（2，0）。首先会对比两者的ZXID,因为都是0，所以无法决定谁是Leader。接下来会对比两者的myid，很显然，Server1发现接收到的投票中的myid为2，大于自己，于是就会更新自己的投票为（2，0），然后重新将投票发出去。而对于Server2来说，不需要更新自己的投票信息，只是再一次向集群中所有机器发出上一次投票信息即可。

4.统计投票

每次投票后，服务器都会统计所有的投票，判断是否已经有过半的机器接收到相同的投票信息。对于Server1和Server2服务器来说，都统计出集群中已经有两台机器接受了（2，0）这个投票信息。这里我们需要对“过半”的概念做一个简单的介绍。所谓“过半”就是指大于集群机器数量的一半，即大于或等于（n/2 + 1）。对于这里由3台机器构成的集群，大于等于2台即为达到“过半”要求。
那么，当Server1和Server2都收到相同的投票信息（2，0）的时候，即认为已经选出了Leader。

5.改变服务器状态

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

二、服务器运行期间的Leader选举

在Zookeeper集群正常运行过程中，一旦选出一个Leader，那么所有服务器的集群角色一般不会再发生变化----也就是说，Leader服务器将一直作为集群的Leader，即使集群中有非Leader集群挂了或是有新机器加入集群也不会影响Leader。但是一旦Leader所在的机器挂了，那么整个集群将暂时无法对外服务，而是进入新一轮的Leader选举。服务器运行期间的Leader选举和启动时期的Leader选举基本过程是一致的。

我们假设当前正在运行的Zookeeper服务器由3台机器组成，分别是Server1、Server2和Server3，当前的Leader是Server2.假设在某个瞬间，Leader挂了，这个时候便开始了Leader选举。

1.变更状态

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

2.每个Server会发出一个投票

在这个过程中，需要生成投票信息（myid，ZXID)。因为是运行期间，因此每个服务器上的ZXID可能不同，我们假定Server1的ZXID为123，而Server3的ZXID为122。在第一轮的投票中，Server1和Server3都会投自己，即分别产生投票（1，123）和（3，122），然后各自将这个投票发给集群中所有机器。

3.接收来自各个服务器的投票

4.处理投票

对于投票的处理，和上面提到的服务器启动时期的处理规则是一致的。在这个例子里面，由于Server1的ZXID为123，Server3的ZXID为122，那么显然，Server1会成为Leader。

5.统计投票

6.改变服务器状态

4、5、6步跟服务器启动时Leader选举相同。

小结

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

说明

1.服务器状态说明

• LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举流程。
• FOLLOWING：跟随者状态，表名当前服务器角色是Follower。
• LEADING：领导者状态，表名当前服务器角色是Leader。
• OBSERVING：观察者状态，表名当前服务器角色是Observer。

[摘抄] 从Paxos到Zookeeper分布式一致性原理与实践