ZooKeeper分析-Leader选举

Posted suixinm

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ZooKeeper分析-Leader选举相关的知识,希望对你有一定的参考价值。

Zookeeper的整体分析,了解了基本的运作原理和整体架构,即分布式系统中协调之力的重要性。本篇我们就来深入分析这个协调服务的服务器启动和Leader选举,带你更深入解读什么叫迷之自信的“自荐式”选举逻辑。

 

服务器启动

 

 

注:ZooKeeper分为单机启动和集群启动两种方式。本文仅分析集群启动这种方式。

 

DatadirCleanupManager

历史文件清理器。从3.4.0版本开始,ZooKeeper增加了自动清理历史数据文件的机制,包括对事务日志和快照数据文件进行定时清理。

 

判断该当前是集群模式还是单机模式启动

根据zoo.cfg中配置的多个服务器地址来判断。

 

QuorumPeer

集群模式下,ZooKeeper服务器实例(ZooKeeperServer)的托管者。代表着集群中的一台机器。在运行期间,它会不断检测当前服务器实例的运行状态,同时根据情况发起Leader选举。

 

恢复本地数据

暂时不做分析。

 

Leader选举

具体实现在后面章节进行分析。

 

源码分析

 

 

 

 

由ZooKeeper的启动脚本中,可以得知,启动器为QuorumPeerMain。继续进入initializeAndRun(args)方法中。

 

 

 

 

 

从配置文件中,可以得知,是否为集群启动方式。当配置为单机启动方式时,默认走ZooKeeperServerMain.main(args)分支。关于单机启动,本文暂时不做分析。继续进入runFromConfig(config)方法中。

 

 

 

 

 

上文已经提到,从3.4.0版本开始,ZooKeeper引入了Netty。可以通过zookeeper.serverCnxnFactory来指定使用具体的实现。静态方法createFactory()方法就是通过反射,调用默认构造函数,获取一个连接工厂的实例。

QuorumPeer意为托管者。在ZooKeeper实例启动时,还未确定身份时,由托管者引导ZooKeeper的启动流程。(它是线程Thread的一个实现类)

接着看runFromConfig(config)的后半段。

 

 

 

 

 

很明显,上面的逻辑就是将参数设置到QuorumPeer的实例中。并由start()方法启动整个ZooKeeper实例。

接着看,start()方法。

 

 

 

 

 

进到这里,主逻辑已经全部展现在眼前了。恢复本地数据暂时不做分析,Leader选举在后面进行分析。

接着,进入startServerCnxnFactory()方法。

 

 

 

 

如果选择Netty的实现作为连接工厂,那么,进入NettyServerCnxnFactory的start()方法。

 

 

 

 

此时,只有一步操作,就是绑定端口。当然了,仅仅绑定端口,是不足以处理发送过来的请求的。那么,关注一下NettyServerCnxnFactory的构造函数。

 

 

 

 

 

 

上文提到过,连接工厂是通过反射获取实例的。也就是说,早在runFromConfig(config)方法中,channelHandler(CnxnChannelHandler是非常重要的类。它是NettyServerCnxnFactory的内部类,实现了Netty的接口,来响应网络事件。)已经设置到Netty中,只是还没有绑定端口。

接着,回到QuorumPeer的start()方法中。

 

 

 

 

在startLeaderElection()方法执行完后,所有逻辑结束了吗?答案是,没有结束。因为QuorumPeer还重写了run()方法。

接着进入run()方法中。

 

 

 

 

这段逻辑几乎可以忽略。

 

 

 

 

 

下面这段逻辑是根据选举后的状态来进行不同角色的初始化流程的。

 

 

在选举结束后,判断自己的选举结果。举例来说,当实例成为Leader时,会走LEADING分支,makeLeader就是创建一个Leader对象。在创建Leader过程中,同时创建了LeaderZooKeeperServer(LeaderZooKeeperServer是非常重要的一个类,它是ZooKeeperServer的一个拓展。)。最后,调用Leader的lead()方法。

接着,进入lead()方法中。

 

 

 

 

 

Leader的lead()方法非常的长,也非常的复杂,其中有一个操作,是将LeaderZooKeeperServer设置到QuorumPeer实例中。Leader对象在创建时,便绑定了QuorumPeer,其变量名为self。(推测:在没有确定服务器的身份时,QuorumPeer作为托管者,来引导服务器的启动,当确定了Leader身份后,程序在QuorumPeer的基础上构建了Leader对象,并认为两者在认知上,是同一个概念。)

接着,进入setZooKeeperServer(zk)方法中。

 

 

 

 

为ServerCnxnFactory (NettyServerCnxnFactory的实例)设置ZooKeeperServer(LeaderZooKeeperServer的实例),所有逻辑便能够串联起来了。

关于Leader和Follower流程,具体的源码实现,暂时不再展开。

 

 

Leader选举

在上文提到过,ZooKeeper提供了三种Leader选举的算法,分别是LeaderElection、UDP版本的FastLeaderElection和TCP版本的FastLeaderElection,可以通过配置文件zoo.cfg中使用electionAlg属性来指定,分别使用数字0~3来表示。从3.4.0版本开始,ZooKeeper废弃了前两种选举算法。下文只介绍第三种算法。

选举的场景

1.服务器初始化启动。

2.服务器运行期间无法和Leader保持连接。

 

算法简述

1.处于LOOKING状态的服务器,将自己作为被推举的对象来进行投票,向集群中的所有其他机器发送消息。在这个投票消息中,包含两个最基本的信息:服务器的SID和ZXID,分别表示了被推举服务器的唯一标识和事务ID。

2.集群中的每台机器在发出自己的投票后,也会接收到来自集群中的其他机器的投票。接着,将收到的和自己的投票进行比较,选择ZXID大的投票重新作为自己的投票(当ZXID一致时,则以SID大的为判断条件),重新发起投票。

3.经过这两次投票后,再次统计投票。如果一台机器收到了超过半数的相同的投票,那么这个投票对应的SID机器即为Leader。

 

图示

 

交互过程

 

 

 

 

QuorumCnxManager

负责每台服务器之间底层Leader选举过程中的网络通信的管理器。在这个类的内部维护了一系列的队列,用于保存接收到的、待发送的消息,以及消息的发送器。

 

SendWorker

消息发送器,对应一台远程的ZooKeeper服务器,负责消息的发送。

 

RecvWorker

消息接收器,不断从TCP连接中读取消息,并将其保存到recvQueue队列中。

 

WorkerSender

选票发送器,会不断从sendqueue队列中获取待发送的选票,并将其传递到底层QuorumCnxManager中去。

 

WorkerReceiver

选票接收器。负责不断从QuorumCnxManager中获取出其他服务器发来的选举消息,并将其转化成一个选票,保存到recvqueue队列中去。

 

选举算法

 

 

 

 

源码分析

 

 

 

进入QuorumPeer的start()方法中,关注startLeaderElection()方法。在上文中,我们跳过了选举的过程,现在开始从这个方法开始切入。

 

先创建一张默认选票,很明显,这张选票是投给自己的。然后,根据选举类型,来获取选举具体的实现。

 

 

这里的代码说明了,ZooKeeper废弃了之前的算法。createCnxnManager()方法创建了QuorumCnxManager对象,负责和其他服务器的底层交互。

进入listener.start()方法中。

 

listener.start()方法,在方法中调用关系比较多,但是最终还是来到上图的逻辑中。在角色定位上,Listener是负责监听端口,创建连接的监听器。为了避免两台机器之间重复创建TCP连接,ZooKeeper设计了一种建立TCP连接的规则:只允许SID大的服务器主动和其他服务器建立连接,否则断开连接。

一旦建立了连接,就会根据远程服务器的SID来创建相应的消息发送器SendWorker和消息接收器ReceWorker,并启动他们。

接着,查看QuorumPeer的run方法。

 

 

 

在listener.start()方法被调用时,连接其实还未创建,在run()方法里,调用了lookForLeader()方法,也就是图示中选举算法的实现的地方。

标识中的代码,初始化选票,并添加到指定队列中。

 

在第一次启动时,上面是变量n肯定为null,并且会走到connectAll()。真正进行连接的地方,也就是在这里。

接着看下面的代码。

 

 

在上面的逻辑中,判断收到的选票的信息,是否为LOOKING状态,接着判断选举轮次是否一致,一致则进行选票PK,如果变更了投票,则发送自己的投票。

 

不管是否变更了投票,都会统计投票,当某个ZooKeeper实例的选票达到半数以上,则确认该服务器为Leader

以上是关于ZooKeeper分析-Leader选举的主要内容,如果未能解决你的问题,请参考以下文章

ZooKeeper分析-Leader选举

ZooKeeper分析-Leader选举

ZOOKEEPER3.3.3源码分析对LEADER选举过程分析的纠正

Zookeeper leader选举

Zookeeper选举原理

zookeeper选举