ZooKeeper详解(六):ZooKeeper的Leader选举

七、ZooKeeper的Leader选举

1、Leader选举概述

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时,需要进入Leader选举

  • 服务器初始化启动

  • 服务器运行期间无法和Leader保持连接

下面就两种情况进行分析讲解

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

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

1)每个Server发出一个投票

由于是初始情况,Server1和Server2都会将自己作为Leader服务器来进行投票,每次投票会包含所推举的服务器的myid和ZXID,使用(myid,ZXID)来表示,此时Server1的投票为(1,0),Server2的投票为(2,0),然后各自将这个投票发给集群中其他机器

2)接受来自各个服务器的投票

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

3)处理投票

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

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

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

4)统计投票

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

5)改变服务器状态

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

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

在Zookeeper运行期间,Leader与非Leader服务器各司其职,即便当有非Leader服务器宕机或新加入,此时也不会影响Leader,但是一旦Leader服务器挂了,那么整个集群将暂停对外服务,进入新一轮Leader选举,其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器,当前Leader是Server2,若某一时刻Leader挂了,此时便开始Leader选举。选举过程如下:

1)变更状态

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

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

在运行期间,每个服务器上的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)改变服务器的状态

2、Leader选举的算法分析

在3.4.0后的Zookeeper的版本只保留了TCP版本的FastLeaderElection选举算法。当一台机器进入Leader选举时,当前集群可能会处于以下两种状态:

  • 集群中已经存在Leader
  • 集群中不存在Leader

对于集群中已经存在Leader而言,此种情况一般都是某台机器启动得较晚,在其启动之前,集群已经在正常工作,对这种情况,该机器试图去选举Leader时,会被告知当前服务器的Leader信息,对于该机器而言,仅仅需要和Leader机器建立起连接,并进行状态同步即可。而在集群中不存在Leader情况下则会相对复杂,其步骤如下:

1)、开始第一次投票

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

在这个投票消息中包含了两个最基本的信息:所推举的服务器的SID和ZXID,分别表示了被推举服务器的唯一标识和事务ID

假设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)

2)、变更投票

每台机器发出投票后,也会收到其他机器的投票,每台机器会根据一定规则来处理收到的其他机器的投票,并以此来决定是否需要变更自己的投票,这个规则也是整个Leader选举算法的核心所在,其中术语描述如下:

  • vote_sid:接收到的投票中所推举Leader服务器的SID
  • vote_zxid:接收到的投票中所推举Leader服务器的ZXID
  • self_sid:当前服务器自己的SID
  • self_zxid:当前服务器自己的ZXID

每次对于收到的投票的处理,都是一个对(vote_sid,vote_zxid)和(self_sid,self_zxid)对比的过程

  • 规则一:如果vote_zxid大于self_zxid,就认可当前收到的投票,并再次将该投票发送出去
  • 规则二:如果vote_zxid小于self_zxid,那么坚持自己的投票,不做任何变更
  • 规则三:如果vote_zxid等于self_zxid,那么就对比两者的SID,如果vote_sid大于self_sid,那么就认可当前收到的投票,并再次将该投票发送出去
  • 规则四:如果vote_zxid等于self_zxid,并且vote_sid小于self_sid,那么坚持自己的投票,不做任何变更

结合上面规则,来分析上面提到的5台机器组成的ZooKeeper集群的投票变更过程:
在这里插入图片描述
每台机器都把投票发出后,同时也会接收到来自另外两台机器的投票:

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

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

上面的例子中,因为ZooKeeper集群的总机器数为5台,那么 q u o r u m = ( 5 / 2 + 1 ) = 3 quorum=(5/2+1)=3 quorum=(5/2+1)=3

也就是说,只要收到3个或三个以上一致的投票即可。在这里,Server3、Server4和Server5都投票(3,9),因此确定了Server3为Leader

3、Leader选举的实现细节

1)、服务器状态

org.apache.zookeeper.server.quorum.QuorumPeer.ServerState枚举类中列举了4中服务器状态,分别是:

  • LOOKING:寻找Leader状态。当服务器处于该状态时,它会认为当前集群中没有Leader,因此需要进入Leader选举流程
  • FOLLOWING:跟随者状态,表明当前服务器角色是Follower
  • LEADING:领导者状态,表明当前服务器角色是Leader
  • OBSERVING:观察者状态,表明当前服务器角色是Observer
2)、投票数据结构

ZooKeeper中对Vote数据结构的定义:

public class Vote {
        
    final private long id;
    
    final private long zxid;
    
    final private long electionEpoch;
    
    final private long peerEpoch;
    
    final private ServerState state;
属性说明
id被推举的Leader的SID值
zxid被推举的Leader的事务ID
electionEpoch逻辑时钟,用来判断多个投票是否在同一轮选举周期中
peerEpoch被推举的Leader的epoch
state当前服务器的状态
3)、QuorumCnxManager:网络I/O

每台服务器启动的时候,都会启动一个QuorumCnxManager,负责各台服务器之间的底层Leader选举过程中的网络通信

1)消息队列

在QuorumCnxManager这个类内部维护了一系列的队列,用于保存接收到的、待发送的消息,以及消息的发送器。除接收队列以外,这里提到的所有队列都有一个共同点——按SID分组形成队列集合,以发送队列为例来说明这个分组的概念。假设集群中除自身外还有4台机器,那么当前服务器就会为这4台服务器分别创建一个发送队列,互不干扰

  • recvQueue:消息接收队列,用于存放哪些从其他服务器接收到的消息
  • queueSendMap:消息发送队列,用于保存那些待发送的消息。queueSendMap是一个Map,按照SID进行分组,分别为集群中的每台机器分配了一个单独队列,从而保证各台机器之间的消息发送互不影响
  • senderWorkerMap:发送器集合。每个SenderWorker消息发送器,都对应一台远程ZooKeeper服务器,负责消息的发送。同样,在senderWorkerMap中也按照SID进行了分组
  • lastMessageSent:最近发送过的消息。在这个集合中,为每个SID保留最近发送过的一个消息

2)建立连接

为了能够相互投票,Zookeeper集群中的所有机器都需要两两建立起网络连接。QuorumCnxManager在启动时会创建一个ServerSocket来监听Leader选举的通信端口(默认为3888)。开启监听后,Zookeeper能够不断地接收到来自其他服务器的创建连接请求,在接收到其他服务器的TCP连接请求时,会进行处理。为了避免两台机器之间重复地创建TCP连接,Zookeeper只允许SID大的服务器主动和其他机器建立连接,否则断开连接。在接收到创建连接请求后,服务器通过对比自己和远程服务器的SID值来判断是否接收连接请求,如果当前服务器发现自己的SID更大,那么会断开当前连接,然后自己主动和远程服务器建立连接。一旦连接建立,就会根据远程服务器的SID来创建相应的消息发送器SendWorker和消息接收器RecvWorker,并启动

3)消息接收与发送

消息接收:由消息接收器RecvWorker负责,由于Zookeeper为每个远程服务器都分配一个单独的RecvWorker,因此,每个RecvWorker只需要不断地从这个TCP连接中读取消息,并将其保存到recvQueue队列中

消息发送:由于Zookeeper为每个远程服务器都分配一个单独的SendWorker,因此,每个SendWorker只需要不断地从对应的消息发送队列中获取出一个消息发送即可,同时将这个消息放入lastMessageSent中。在SendWorker中,一旦Zookeeper发现针对当前服务器的消息发送队列为空,那么此时需要从lastMessageSent中取出一个最近发送过的消息来进行再次发送,这是为了解决接收方在消息接收前或者接收到消息后服务器挂了,导致消息尚未被正确处理。同时,Zookeeper能够保证接收方在处理消息时,会对重复消息进行正确的处理

4)、FastLeaderElection:选举算法核心
  • 外部投票:特指其他服务器发来的投票
  • 内部投票:服务器自身当前的投票
  • 选举轮次:Zookeeper服务器Leader选举的轮次,即logicalclock
  • PK:对内部投票和外部投票进行对比来确定是否需要变更内部投票

1)选票管理

  • sendqueue:选票发送队列,用于保存待发送的选票
  • recvqueue:选票接收队列,用于保存接收到的外部投票
  • WorkerReceiver:选票接收器。其会不断地从QuorumCnxManager中获取其他服务器发来的选举消息,并将其转换成一个选票,然后保存到recvqueue中,在选票接收过程中,如果发现该外部选票的选举轮次小于当前服务器的,那么忽略该外部投票,同时立即发送自己的内部投票
  • WorkerSender:选票发送器,不断地从sendqueue中获取待发送的选票,并将其传递到底层QuorumCnxManager中

2)算法核心
在这里插入图片描述
上图展示了FastLeaderElection模块是如何与底层网络I/O进行交互的。Leader选举的基本流程如下:

1)自增选举轮次。Zookeeper规定所有有效的投票都必须在同一轮次中,在开始新一轮投票时,会首先对logicalclock进行自增操作

2)初始化选票。在开始进行新一轮投票之前,每个服务器都会初始化自身的选票,并且在初始化阶段,每台服务器都会将自己推举为Leader

3)发送初始化选票。完成选票的初始化后,服务器就会发起第一次投票。Zookeeper会将刚刚初始化好的选票放入sendqueue中,由发送器WorkerSender负责发送出去

4)接收外部投票。每台服务器会不断地从recvqueue队列中获取外部选票。如果服务器发现无法获取到任何外部投票,那么就会立即确认自己是否和集群中其他服务器保持着有效的连接,如果没有连接,则马上建立连接,如果已经建立了连接,则再次发送自己当前的内部投票

5)判断选举轮次。在发送完初始化选票之后,接着开始处理外部投票。在处理外部投票时,会根据选举轮次来进行不同的处理

  • 外部投票的选举轮次大于内部投票:若服务器自身的选举轮次落后于该外部投票对应服务器的选举轮次,那么就会立即更新自己的选举轮次(logicalclock),并且清空所有已经收到的投票,然后使用初始化的投票来进行PK以确定是否变更内部投票。最终再将内部投票发送出去
  • 外部投票的选举轮次小于内部投票:若服务器接收的外选票的选举轮次落后于自身的选举轮次,那么Zookeeper就会直接忽略该外部投票,不做任何处理,并返回步骤4
  • 外部投票的选举轮次等于内部投票:此时可以开始进行选票PK

6)选票PK。在进行选票PK时,符合任意一个条件就需要变更投票

  • 若外部投票中推举的Leader服务器的选举轮次大于内部投票,那么需要变更投票

  • 若选举轮次一致,那么就对比两者的ZXID,若外部投票的ZXID大,那么需要变更投票

  • 若两者的ZXID一致,那么就对比两者的SID,若外部投票的SID大,那么就需要变更投票

7)变更投票。经过PK后,若确定了外部投票优于内部投票,那么就变更投票,即使用外部投票的选票信息来覆盖内部投票,变更完成后,再次将这个变更后的内部投票发送出去

8)选票归档。无论是否变更了投票,都会将刚刚收到的那份外部投票放入选票集合recvset中进行归档recvset用于记录当前服务器在本轮次的Leader选举中收到的所有外部投票(按照服务队的SID区别,如{(1, vote1), (2, vote2)...}

9)统计投票。完成选票归档后,就可以开始统计投票,统计投票是为了统计集群中是否已经有过半的服务器认可了当前的内部投票,如果确定已经有过半服务器认可了该投票,则终止投票。否则返回步骤4

10)更新服务器状态。若已经确定可以终止投票,那么就开始更新服务器状态,服务器首选判断当前被过半服务器认可的投票所对应的Leader服务器是否是自己,若是自己,则将自己的服务器状态更新为LEADING,若不是,则根据具体情况来确定自己是FOLLOWING或是OBSERVING

以上10个步骤就是FastLeaderElection的核心,其中步骤4-9会经过几轮循环,直到有Leader选举产生

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

邋遢的流浪剑客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值