Zookeeper选举leader过程

1.1 Leader选举概述

        Leader选举是ZooKeeper中最重要的技术之一，也是保证分布式数据一致性的关键所在。

1.1.1 服务器启动时期的Leader选举

        我们讲解Leader选举的时候，隐式条件便是ZooKeeper的集群规模至少是2台机器，这里我们以3台机器组成的服务器集群为例。在服务器集群初始化阶段，当有一台服务器（Server1，myid为1）启动的时候，它是无法完成Leader选举的，也是无法进行Leader选举的。当第二台机器（Server1，myid为1）也启动后，此时这两台机器已经能够相互通信，每台机器都试图找到一个Leader，于是便进入了Leader选举流程。

a.每个Server会发出一个投票。

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

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

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

c.处理投票。

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

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

      对于Server1来说，它自己的投票是（1，0），而接收的投票是（2，0），经过PK发现大于自己的投票，于是更新自己的投票为（2，0），然后重新将投票发出去。而对于Server2来说，不需要更新自己的投票信息，只是再一次向集群中所有机器发出上一次的投票信息即可。

d.统计投票。

      每次投票之后，服务器都会统计所有投票，判断是否已经有过半(>= n/2 + 1)的机器接收到相同的投票信息。对于Server1和Server2服务器来说，都统计出集群中已经有两台服务器接收（2，0）这个投票信息。当Server1和Server2都收到相同的投票（2，0）的时候，即认为已经选出了Leader。

e.改变服务器状态。

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

1.1.2 服务器运行期间的Leader选举

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

a.变更状态。

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

b.每个Server会发出一个投票。

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

d.处理投票。

e.统计投票。

f.改变服务器状态。

1.2 Leader选举的算法分析

从3.4.0版本开始，ZooKeeper只保留了TCP版本的FatLeaderElection选举算法，本小节主要讲这个算法，首先了解几个概念。

• SID：    服务器ID。SID是一个数字，用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
• ZXID：  事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
• Vote：   投票。Leader选举通过投票来实现。当集群中的机器发现自己无法检测到Leader机器的时候，就会开始尝试进行投票。
• QuoRum：过半机器数。quorum = (n/2 + 1),n为机器总数。

1.2.1 进入Leader选举

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

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

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

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

   对于第一种已经存在Leader的情况，机器试图去选举Leader的时候，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。

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

1.2.2 开始第一次投票

        当集群中不存在Leader时，集群中的所有机器都处于一种试图选举出一个Leader的状态，这种状态为LOOKING。当一台服务器处于LOOKING状态的时候，那么它就会向集群中所有其它机器发送消息，我们称这个消息为“投票”。投票包含SID和ZXID，分别表示被推举服务器的唯一标识和事务ID。用（SID，ZXID）表示一个投票信息。

       我们假设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）。

3.2.3 变更投票

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

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

每次对于收到的投票的处理，都是对（vote_sid，vote_sid）和（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，那么就比较两者的SID。如果vote_sid小于self_sid，那么就坚持坚持自己的投票，不做任何变更。

   对于上面这个规则，我们分析上面提到例子的选举过程，如果所示。

1.2.4 确定leader

      经过第二次投票之后，集群中的每台机器都会再次收到其他机器的投票，然后开始统计投票。如果每台机器收到超过半数的相同的投票，那么这个投票对应的SID机器即为Leader。上面例子中，ZooKeeper集群的总机器数为5。quorum=（5/2 + 1）= 3。也就是说，只要收到3个或者3个以上（含当前服务器自身在内）一致的投票即可，Server3、Server4和Server5都投票（3，9），因此确定了Server3为Leader。

1.2.5 小结

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

1.3 Leader选举的实现细节

        通过上一小节介绍Leader选举的算法设计，从算法复杂度看，FastLeaderElection算法的设计并不复杂，但在真正实现过程中，