zookeeper选举机制

阅读时参考的版本是3.3.3.

简单的说一下zookeeper工作的过程,如果对这个过程还不太清楚,或者说对它如何使用等不太清楚的,可以参考一下其他的文章,比如这篇,这一系列的文章将不讲解它如何使用(实际上我也没有在具体项目中使用过,只是简单的配置运行起来大概晓得如何工作而已).

zookeeper有两种工作的模式,一种是单机方式,另一种是集群方式.单机方式不属于这里分析的范畴,因为研究zookeeper的目的就在于研究一个zookeeper集群的机器如何协调起来工作的.

要配置几台zookeeper一起工作,大家在开始必须使用相同的配置文件,配置文件中有一些配置项,但是与集群相关的是这一项:

server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888

这里定义了两台服务器的配置,格式为:

server.serverid=serverhost:leader_listent_port:quorum_port

顾名思义,serverid是本服务器的id,leader_listen_port是该服务器一旦成为leader之后需要监听的端口,用于接收来自follower的请求,quorum_port是集群中的每一个服务器在最开始选举leader时监听的端口,用于服务器互相之间通信选举leader.

需要注意的是,server id并没有写在这个配置文件中,而是在datadir中的myid文件中指定,我理解这么做的目的是:所有的服务器统一使用一个配置文件,该配置文件里面没有任何与特定服务器相关的信息,这样便于发布服务的时候不会出错,而独立出来一个文件专门存放这个server id值.

zookeeper集群工作的过程包括如下几步:
1) recovery,这个过程泛指集群服务器的启动和恢复,因为恢复也可以理解为另一种层面上的”启动”–需要恢复历史数据的启动,后面会详细讲解.
2) broadcast,这是启动完毕之后,集群中的服务器开始接收客户端的连接一起工作的过程,如果客户端有修改数据的改动,那么一定会由leader广播给follower,所以称为”broadcast”.

展开来说,zookeeper集群大概是这样工作的:
1) 首先每个服务器读取配置文件和数据文件,根据serverid知道本机对应的配置(就是前面那些地址和端口),并且将历史数据加载进内存中.
2) 集群中的服务器开始根据前面给出的quorum port监听集群中其他服务器的请求,并且把自己选举的leader也通知其他服务器,来来往往几回,选举出集群的一个leader.
3) 选举完leader其实还不算是真正意义上的”leader”,因为到了这里leader还需要与集群中的其他服务器同步数据,如果这一步出错,将返回2)中重新选举leader.在leader选举完毕之后,集群中的其他服务器称为”follower”,也就是都要听从leader的指令.
4) 到了这里,集群中的所有服务器,不论是leader还是follower,大家的数据都是一致的了,可以开始接收客户端的连接了.如果是读类型的请求,那么直接返回就是了,因为并不改变数据;否则,都要向leader汇报,如何通知leader呢?就是通过前面讲到的leader_listen_port.leader收到这个修改数据的请求之后,将会广播给集群中其他follower,当超过一半数量的follower有了回复,那么就相当于这个修改操作哦了,这时leader可以告诉之前的那台服务器可以给客户端一个回应了.
可以看到,上面1),2),3)对应的recovery过程,而4)对应的broadcast过程.

这里只是简单的描述了一下zookeeper集群的工作原理,后面将分别展开来讨论.

link:http://www.codedump.info/?p=210

link:http://www.codedump.info/?p=224

如何在zookeeper集群中选举出一个leader,zookeeper使用了三种算法,具体使用哪种算法,在配置文件中是可以配置的,对应的配置项是”electionAlg”,其中1对应的是LeaderElection算法,2对应的是AuthFastLeaderElection算法,3对应的是FastLeaderElection算法.默认使用FastLeaderElection算法.其他两种算法我没有研究过,就不多说了.

要理解这个算法,最好需要一些paxos算法的理论基础.

1) 数据恢复阶段
首先,每个在zookeeper服务器先读取当前保存在磁盘的数据,zookeeper中的每份数据,都有一个对应的id值,这个值是依次递增的,换言之,越新的数据,对应的ID值就越大.

2) 向其他节点发送投票值
在读取数据完毕之后,每个zookeeper服务器发送自己选举的leader（首次选自己）,这个协议中包含了以下几部分的数据:
    a)所选举leader的id(就是配置文件中写好的每个服务器的id) ,在初始阶段,每台服务器的这个值都是自己服务器的id,也就是它们都选举自己为leader.
    b) 服务器最大数据的id,这个值大的服务器,说明存放了更新的数据.
    c)逻辑时钟的值,这个值从0开始递增,每次选举对应一个值,也就是说:  如果在同一次选举中,那么这个值应该是一致的 ;  逻辑时钟值越大,说明这一次选举leader的进程更新.
    d) 本机在当前选举过程中的状态,有以下几种:LOOKING,FOLLOWING,OBSERVING,LEADING,顾名思义不必解释了吧.

3）接受来自其他节点的数据

每台服务器将自己服务器的以上数据发送到集群中的其他服务器之后,同样的也需要接收来自其他服务器的数据,它将做以下的处理:
（1）如果所接收数据中服务器的状态还是在选举阶段(LOOKING 状态),那么首先判断逻辑时钟值,又分为以下三种情况:
     a) 如果发送过来的逻辑时钟大于目前的逻辑时钟,那么说明这是更新的一次选举,此时需要更新一下本机的逻辑时钟值,同时将之前收集到的来自其他服务器的选举清空,因为这些数据已经不再有效了.然后判断是否需要更新当前自己的选举情况.在这里是根据选举leader id,保存的最大数据id来进行判断的,这两种数据之间对这个选举结果的影响的权重关系是:首先看数据id,数据id大者胜出;其次再判断leader id,leader id大者胜出.然后再将自身最新的选举结果(也就是上面提到的三种数据）广播给其他服务器).

    b) 发送过来数据的逻辑时钟小于本机的逻辑时钟，说明对方在一个相对较早的选举进程中,这里只需要将本机的数据发送过去就是了

    c) 两边的逻辑时钟相同,此时也只是调用totalOrderPredicate函数判断是否需要更新本机的数据,如果更新了再将自己最新的选举结果广播出去就是了.

然后再处理两种情况:
    1)服务器判断是不是已经收集到了所有服务器的选举状态,如果是，那么这台服务器选举的leader就定下来了，然后根据选举结果设置自己的角色(FOLLOWING还是LEADER),然后退出选举过程就是了.
    2)即使没有收集到所有服务器的选举状态,也可以根据该节点上选择的最新的leader是不是得到了超过半数以上服务器的支持,如果是,那么当前线程将被阻塞等待一段时间(这个时间在finalizeWait定义)看看是不是还会收到当前leader的数据更优的leader,如果经过一段时间还没有这个新的leader提出来，那么这台服务器最终的leader就确定了,否则进行下一次选举. 

（2) 如果所接收服务器不在选举状态,也就是在FOLLOWING或者LEADING状态

做以下两个判断:
    a) 如果逻辑时钟相同,将该数据保存到recvset,如果所接收服务器宣称自己是leader,那么将判断是不是有半数以上的服务器选举它,如果是则设置选举状态退出选举过程
    b) 否则这是一条与当前逻辑时钟不符合的消息,那么说明在另一个选举过程中已经有了选举结果,于是将该选举结果加入到outofelection集合中,再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟,设置选举状态,退出选举过程.
代码如下:



以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.
1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.

以上就是fastleader算法的简要分析,还有一些异常情况的处理,比如某台服务器宕机之后的处理,当leader宕机之后的处理等等,后面再谈.

      根据 Fast Leader选举算法中的分析,如果一台zookeeper服务器成为集群中的leader,那么一定是当前所有服务器中保存数据最多（不是最新？？）的服务器,所以在这台服务器成为leader之后,首先要做的事情就是与集群中的其它服务器(现在是follower)同步数据,保证大家的数据一致,这个过程完毕了才开始正式处理来自客户端的连接请求.

      Fast Leader选举算法中提到的同步数据时使用的逻辑时钟,它的初始值是0,每次选举过程都会递增的,在leader正式上任之后做的第一件事情,就是根据当前保存的数据id值,设置最新的逻辑时钟值。

    随后,leader构建NEWLEADER封包,该封包的数据是当前最大数据的id,广播给所有的follower,也就是告知follower leader保存的数据id是多少,大家看看是不是需要同步。然后,leader根据follower数量给每个follower创建一个线程LearnerHandler,专门负责接收它们的同步数据请求.leader主线程开始阻塞在这里,等待其他follower的回应(也就是LearnerHandler线程的处理结果),同样的,只有在超过半数的follower已经同步数据完毕,这个过程才能结束,leader才能正式成为leader.

leader所做的工作：

所以其实leader与follower同步数据的大部分操作都在LearnerHandler线程中处理的,接着看这一块.
leader接收到的来自某个follower封包一定是FOLLOWERINFO,该封包告知了该服务器保存的数据id.之后根据这个数据id与本机保存的数据进行比较:
1) 如果数据完全一致,则发送DIFF封包告知follower当前数据就是最新的了.
2) 判断这一阶段之内有没有已经被提交的提议值,如果有,那么:
    a) 如果有部分数据没有同步,那么会发送DIFF封包将有差异的数据同步过去.同时将follower没有的数据逐个发送COMMIT封包给follower要求记录下来.
    b) 如果follower数据id更大,那么会发送TRUNC封包告知截除多余数据.（一台leader数据没同步就宕掉了，选举之后恢复了，数据比现在leader更新）
3) 如果这一阶段内没有提交的提议值,直接发送SNAP封包将快照同步发送给follower.
4）消息完毕之后,发送UPTODATE封包告知follower当前数据就是最新的了,再次发送NEWLEADER封包宣称自己是leader,等待follower的响应.

follower做的工作：
（1）会尝试与leader建立连接,这里有一个机制,如果一定时间内没有连接上,就报错退出,重新回到选举状态.
（2）其次在发送FOLLOWERINFO封包,该封包中带上自己的最大数据id,也就是会告知leader本机保存的最大数据id.
（3）根据前面对LeaderHandler的分析,leader会根据不同的情况发送DIFF,UPTODATE,TRUNC,SNAP,依次进行处理就是了,此时follower跟leader的数据也就同步上了.
（4）由于leader端发送的最后一个封包是UPTODATE,因此在接收到这个封包之后follower结束同步数据过程,发送ACK封包回复leader.

以上过程中,任何情况出现的错误,服务器将自动将选举状态切换到LOOKING状态,重新开始进行选举.

master选举

1、使用场景及结构

　　现在很多时候我们的服务需要7*24小时工作，假如一台机器挂了，我们希望能有其它机器顶替它继续工作。此类问题现在多采用master-salve模式，也就是常说的主从模式，正常情况下主机提供服务，备机负责监听主机状态，当主机异常时，可以自动切换到备机继续提供服务(这里有点儿类似于数据库主库跟备库，备机正常情况下只监听，不工作)，这个切换过程中选出下一个主机的过程就是master选举。

　　对于以上提到的场景，传统的解决方式是采用一个备用节点，这个备用节点定期给当前主节点发送ping包，主节点收到ping包后会向备用节点发送应答ack，当备用节点收到应答，就认为主节点还活着，让它继续提供服务，否则就认为主节点挂掉了，自己将开始行使主节点职责。如图1所示：

　　　　              图1                                                                                                                                

　　　但这种方式会存在一个隐患，就是网络故障问题。看一下图2：

　　　　　　　　　　图2

　　　也就是说，我们的主节点并没有挂掉，只是在备用节点ping主节点，请求应答的时候发生网络故障，这样我们的备用节点同样收不到应答，就会认为主节点挂掉，然后备机会启动自己的master实例。这样就会导致系统中有两个主节点，也就是双master。出现双master以后，我们的从节点会将它做的事情一部分汇报给主节点，一部分汇报给备用节点，这样服务就乱套了。为了防止这种情况出现，我们可以考虑采用zookeeper，虽然它不能阻止网络故障的出现，但它能保证同一时刻系统中只存在一个主节点。我们来看zookeeper是怎么实现的：

　　在此处，抢主程序是包含在服务程序中，需要程序员来手动写抢主逻辑的，比如当当开源框架elastic-job中，就有关于选主的部分，参见：elastic-job-core/main/java/com/dangdang/ddframe/job/internal/election文件夹下的选主代码。

　　一点额外的话：zookeeper自己在集群环境下的抢主算法有三种，可以通过配置文件来设定，默认采用FastLeaderElection，不作赘述；此处主要讨论集群环境中，应用程序利用master的特点，自己选主的过程。程序自己选主，每个人都有自己的一套算法，有采用“最小编号”的，有采用类似“多数投票”的，各有优劣，本文的算法仅作演示理解使用：

　　结构图：

　　结构图解释：左侧树状结构为zookeeper集群，右侧为程序服务器。所有的服务器在启动的时候，都会订阅zookeeper中master节点的删除事件，以便在主服务器挂掉的时候进行抢主操作；所有服务器同时会在servers节点下注册一个临时节点（保存自己的基本信息），以便于应用程序读取当前可用的服务器列表。

　　选主原理介绍：zookeeper的节点有两种类型，持久节点跟临时节点。临时节点有个特性，就是如果注册这个节点的机器失去连接(通常是宕机)，那么这个节点会被zookeeper删除。选主过程就是利用这个特性，在服务器启动的时候，去zookeeper特定的一个目录下注册一个临时节点(这个节点作为master，谁注册了这个节点谁就是master)，注册的时候，如果发现该节点已经存在，则说明已经有别的服务器注册了(也就是有别的服务器已经抢主成功)，那么当前服务器只能放弃抢主，作为从机存在。同时，抢主失败的当前服务器需要订阅该临时节点的删除事件，以便该节点删除时(也就是注册该节点的服务器宕机了或者网络断了之类的)进行再次抢主操作。从机具体需要去哪里注册服务器列表的临时节点，节点保存什么信息，根据具体的业务不同自行约定。选主的过程，其实就是简单的争抢在zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。

　　ps：本文的例子中，并未用到结构图server节点下的数据。但换一种算法或者业务场景就会用到，算法比如提到的最小编号，主要逻辑是主节点挂掉后，从节点里边编号最小的成为主节点，此时会用到该节点内容。换一种业务场景：集群环境中，有很多任务要处理， 主节点负责接收任务，并根据一定算法将任务分配到不同的机器上执行；这种情况下，主节点跟从节点的职责也是不同的，主节点挂掉也会涉及到从节点进行master选举的问题。这种情况下，很显然，作为主节点需要知道当前有多少个从节点还活着，那么此时也会需要用到servers节点下的数据了。

2、编码实现

 　　主要有两个类，WorkServer为主服务类，RunningData用于记录运行数据。因为是简单的demo，我们只做抢master节点的编码，对于从节点应该去哪里注册服务列表信息，不作编码。

　　采用zkClient实现，代码如下：

　　WorkServer类：

　　 View Code

　　RunningData类：

    View Code

 　　说明：在实际生产环境中，可能会由于插拔网线等导致网络短时的不稳定，也就是网络抖动。由于正式生产环境中可能server在zk上注册的信息是比较多的，而且server的数量也是比较多的，那么每一次切换主机，每台server要同步的数据量(比如要获取谁是master，当前有哪些salve等信息，具体视业务不同而定)也是比较大的。那么我们希望，这种短时间的网络抖动最好不要影响我们的系统稳定，也就是最好选出来的master还是原来的机器，那么就可以避免发现master更换后，各个salve因为要同步数据等导致的zk数据网络风暴。所以在WorkServer中，54-63行，我们抢主的时候，如果之前主机是本机，则立即抢主，否则延迟5s抢主。这样就给原来主机预留出一定时间让其在新一轮选主中占据优势，从而利于环境稳定。

　　测试代码：

    View Code

　　两次测试，本地模拟10台server，分别不启用防止网络抖动跟启动防抖动两次测试结果如下：

　　未启动防抖动：

　　启用防抖动：

　　可以看到，未启用的时候，断线后重新选出的主机是随机的，没规律；启用防抖动后，每次选出的master都是id为0的机器。

-----------------------------------------------------------------------------------------------------------------------------

　　至此，我们已经通过编码实现了简单的master选举。但是，不知你有没有发现，，，，这个选主过程的代码还真是麻烦啊！

　　我们只是做一个demo，其中并未考虑复杂的业务场景，但其中的  监听，异常  等代码的处理还是让我觉得有些头大，怎么办？Curator应运而生！

　　为了熟悉Apache Curator，接下来，将用curator来实现master选举的demo。