1 选举流程
Leader选举是ZooKeeper中最重要的技术之一，也是保证分布式数据一致性的关键所在。Zookeeper提供了三种方式进行Leader选举：LeaderElection、AuthFastLeaderElection、FastLeaderElection，默认算法是FastLeaderElection，所以这篇主要分析它的选举机制。
1.1 启动时期
Leader选举的隐式条件是ZooKeeper的集群规模至少是2台机器，这里以3台机器组成的服务器集群为例。
在服务器集群初始化阶段，当有一台服务器（server1，myid为1）启动的时候，它是无法进行Leader选举的。当第二台机器（server2，myid为2）也启动后，此时这两台机器已经能够相互通信，每台机器都试图找到一个Leader，于是便进入了Leader选举流程。
- step1：每个server发出一个投票
由于是初始情况，因此对于server1和server2来说，都会将自己作为Leader服务器来进行投票，每次投票包含的基本元素包括：所推举的服务器的sid、zxid、epoch。初始化阶段，无论server1还是server2，都会投给自己，即server1的投票为（1，0，1），server2的投票为（2，0，1），然后各自将这个投票发给集群中其它所有机器。
- step：接收来自各个服务器的投票
每个服务器都会接受来自其它服务器的投票。集群中的每一台服务器在接收到投票后，首先会判断该投票的有效性，包括检查是否是本轮投票（根据逻辑时钟epoch），是否来自LOOKING状态的服务器。
- step3：处理投票
在接收到来自其它服务器的投票后，针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK。PK的规则如下：
(1)、判断逻辑时钟值。如果发送过来的逻辑时钟epoch大于目前的逻辑时钟。首先，更新本逻辑时钟epoch，同时清空本逻辑时钟收集到的来自其他server的选举数据。然后，根据【判断规则】判断是否需要更新当前自己的选举sid。最后再将自身最新的选举结果即（sid，zxid，epoch）广播给其他server。
(2)、如果发送过来的逻辑时钟epoch小于目前的逻辑时钟。说明对方server在一个相对较早的epoch中，这里只需要将本机的三种数据（sid，zxid，epoch）发送过去就行。
(3)、如果发送过来的逻辑时钟Epoch等于目前的逻辑时钟。再根据【判断规则】来选举leader ，然后再将自身最新的选举结果（sid，zxid，epoch）广播给其他server。
【判断规则】
(1)、优先检查ZXID。ZXID比较大的服务器优先作为Leader。
(2)、如果ZXID相同的话，那么就比较myid。myid比较大的服务器作为Leader服务器。
对于server1来说，它自己的投票是（1，0，1），而接收的投票是（2，0，1），经过PK后发现大于自己的投票，于是更新自己的投票为（2，0，1），然后重新将投票发出去。而对于server2来说，不需要更新自己的投票信息，只是再一次向集群中所有机器发出上一次的投票信息即可。
- step4：统计投票
每次投票之后，服务器都会统计所有投票，判断是否已经有过半(>= n/2 + 1)的机器接收到相同的投票信息。对于server1和server2服务器来说，都统计出集群中已经有两台服务器接收（2，0）这个投票信息。当server1和server2都收到相同的投票（2，0）的时候，即认为已经选出了Leader。
- step5：改变服务器状态
一旦确定了Leader，每个服务器就会更新自己的状态：如果是Follower，那么久变更为FOLLOWING，如果是Leader，那么就变更LEADING为。
1.2 服务时期
在ZooKeeper集群正常运行过程中，一旦选出一个Leader，那么所有服务器的角色一般都不会再发生变化，Leader服务器将一直作为集群的Leader，即使集群中有非Leader服务器挂了或者是有新的机器加入集群也不会影响原来的Leader。但是一旦Leader所在的机器挂了，那么这个集群将暂时无法对外提供服务，而是进去新一轮的Leader选举。服务器运行期间的Leader选举和启动时期的Leader选举过程基本一致。
- step0：变更状态
当Leader挂了之后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举流程。
- step1：每个Server会发出一个投票
- step2：接收来自各个服务器的投票
- step3：处理投票
- step4：统计投票
- step5：改变服务器状态
2 选举算法
从3.4.0版本开始，ZooKeeper只保留了TCP版本的FatLeaderElection选举算法，讲解这个算法前先了解几个概念。
- SID：服务器ID。SID是一个数字，用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
- ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
- Epoch：逻辑时钟或者投票次数。同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
- Vote：投票。Leader选举通过投票来实现。当集群中的机器发现自己无法检测到Leader机器的时候，就会开始尝试进行投票。
- QuoRum：过半机器数。quorum = (n/2 + 1)，n为机器总数。
2.1 进入选举
当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：
- 服务器初始化启动。
- 服务器运行期间无法和Leader保持连接。
而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：
- 集群中本来就已经存在一个Leader。
- 集群中确实不存在Leader。
对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
下面重点来看集群中不存在Leader的情况，如何进行Leader选举。
2.2 开始投票
当集群中不存在Leader时，集群中的所有机器都处于一种试图选举出一个Leader的状态，这种状态为LOOKING。当一台服务器处于LOOKING状态的时候，那么它就会向集群中所有其它机器发送消息，我们称这个消息为“投票”。投票包含SID、ZXID、EPOCH。分别表示被推举服务器的唯一标识、事务ID、逻辑时钟/投票轮数。用（SID，ZXID，EPOCH）表示一个投票信息。
假设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，1）、（4，8，1）、（5，8，1）。
2.3 变更投票
集群中的每台机器发出投票后，也会接收到来自集群中其它机器的投票。每台机器都会根据一定的规则，来处理收到的其它机器的投票，并以此来决定是否需要变更自己的投票。这个投票也成为了整个Leader选举算法的核心所在。先定义以下术语。
- vote_sid：接收到的投票中所推举Leader服务器的SID。
- vote_sid: 接收到的投票中所推举Leader服务器的ZXID。
- self_sid: 当前服务器自己的SID。
- self_zxid: 当前服务器自己的ZXID。
每次对于收到的投票的处理，先判断epoch，然后就是对（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，那么就坚持坚持自己的投票，不做任何变更。
2.4 确定leader
经过第二次投票之后，集群中的每台机器都会再次收到其他机器的投票，然后开始统计投票。如果每台机器收到超过半数的相同的投票，那么这个投票对应的SID机器即为Leader。上面例子中，ZooKeeper集群的总机器数为5。quorum=（5/2 + 1）= 3。也就是说，只要收到3个或者3个以上（含当前服务器自身在内）一致的投票即可，Server3、Server4和Server5都投票（3，9），因此确定了Server3为Leader。
参考文章：
2704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
