第四章 Leader选举算法分析

　　Leader选举

　　学习leader选举算法，主要是从选举概述，算法分析与源码分析（后续章节写）三个方面进行。

　　Leader选举概述

　　服务器启动时期的Leader选举

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

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

　　初试启动时，Serverl和Server2都选举自己为leader，每次投票包含的最基本的元素包括：所推举的服务器的myid和ZXID，以（myid， ZX1D)的形式来表示。即Serverl的投票为（1, 0)， Server2的投票为（2, 0)，然后各自将这个投票发给集群中其他所有机器。

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

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

　　3. 处理投票。

　　针对收到的每一张选票，都需要将別人的投票和自己的投票进行PK， PK的规则如下：

　　　　a.首先比较ZXID。 ZXID大的选票胜出。

　　　　b.当ZXID相同时，myid大的选票胜出。
　　对于Server1来说，初试投票是(1,0) ,接收到的投票为(2,0)。两者的ZXID都是0,对比两者的myid, Server1接收到的投票中的myid是2,大于自己，于是就会更新自己的投票为（2,0)，然后重新将投票发出去。对于Server2来说，不需要更新自己的投票信息，只是再一次向集群中所有机器发出上一次投票信息。
　　4. 统计投票。
　　每次投票后，服务器都会统计所有投票，如果一台机器收到超过半数的相同的投票，那么这个投票对应的SID机器即成为Leader。对于Server1和Server2服务器来说，都统计收到（2, 0)这个投票信息两票。

　　5. 改变服务器状态。

　　服务器运行期间的Leader选举

　　当leader所在的机器挂了，整个集群将暂时无法对外提供服务，集群进入新一轮的leader选举。服务器运行期间的Leader选举和启动时期的Leader选举基本过程是一致。假设当前正在运行的ZooKeeper服务器由3台机器组成，分别是Server1、 Server2和Server3,当前的Leader是Server2,在某一个瞬间， Leader挂了。

　　1.变更状态

　　Follower将状态变更为LOOKING

　　2.每个Server发出一个投票　　　　

　　假定Served的ZXID为123 ,而Server3的ZXID为122。在第一轮投票中， Server1和Server3都会投自己，即分别产生投票（1,123）和（3， 122）,然后各自将这个投票发给集群中所有机器。

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

　　4.处理投票

　　根据选票PK规则，server1的投票胜出。Server3将自己的选票变更为（1,123）重新投出。

　　5.统计投票

　　6.改变服务器状态

　　算法分析

　　在ZooKeeper中，提供了三种Leader选举的算法，分别是LeaderElection'、UDP版本的FastLeaderElection 和 TCP 版本的 FastLeaderElection，可以通过在配置文件 zoo.cfg中使用electionAlg属性来指定，分别使用数字0~3来表示。0代表LeaderElection,这是一种纯UDP实现的Leader选举算法；1代表UDP版本的FastLeaderElection,并且是非授权模式； 2也代表UDP版本的FastLeaderElection,但使用授权模式；3代表TCP版本的FastLeaderElection。从3.4.0版本开始， ZooKeeper废弃了 0、1和2这三种Leader选举算法，只保留了 TCP版本的FastLeaderElection选举算法。

　　关于进入Leader选举

　　当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进人Leader选举。
　　　　a.服务器初始化启动。
　　　　b.服务器运行期间无法和Leader保持连接。
　　当一台机器进人Leader选举流程时，当前集群也可能会处于以下两种状态。
　　　　a.集群中本来就已经存在一个Leader。
　　　　b.集群中确实不存在Leader。

　　第一种已经存在Leader的情况通常是集群中的某一台机器启动比较晚，在它启动之前，集群已经可以正常工作，即已经存在了一台Leader服务器。针

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

　　

　　关于变更选票

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

　　• vote_sid:接收到的投票中所推举Leader服务器的SID。
　　• vote_zxid:接收到的投票中所推举Leader服务器的ZXID。
　　• self_sid:当前服务器自己的SID。
　　• self_zxid:当前服务器自己的ZXID。
　　每次对干收到的投票的处理，都是一个对(vote_sid, vote_zxid)和(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, 并 且 vote_sid小于self_sid,那么同样坚持自己的投票，不做变更。