[TOC]
前言
Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。
- 服务器初始化启动。
- 服务器运行期间无法和Leader保持连接。
leader的选择机制，zookeeper提供了三种方式：
- LeaderElection
- AuthFastLeaderElection
- FastLeaderElection （最新默认,也是本文主角）
下面就两种情况进行分析讲解。
服务器[启动]时期的Leader选举
个人简述: 初始启动时,每台机器都投自己,然后通知其他机器(通知的这个过程就叫投票),通知本质是发送消息,携带了(leaderId,zxid,Epoch),初始值就是(1,0,0),
(每个机器都投票,都判别)然后其他机器收到消息,进行判断,用收到的消息和自己的消息判别,
首先看是否为本轮选举(别人是新选举就更新自己,自己是新选举就通知它更新),然后比较zxid,如果一样再比较leaderId(都是取大值,所以配置文件中要求brokenId不能重复),比较后的结果如果与本地不同,则更新本地并通知其他机器,反之不动. 服务器还会判断,是否收集到了所有服务器的选举状态或者是否有过半机器(此时还会等200ms,看有没有新的消息),根据结果设置自己该成为leader还是follower,然后退出选举,kafka就能正常用了,如果已经产生leader,新加入的机器自动成为follower,同步数据即可
说明:
- leaderId:机器所认为的leader ID,这个ID值就是配置文件中的brokenId
- zxid: 数据值,每次kafka中更新值就会更新这个值(zxid越大,数据越新)
- Epoch: 逻辑时钟值, 用于判断是否为本轮选举,每次选举都自动递增
若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下
(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下
- 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
- 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。
以上这是两台的场景,
如果是三台, 按顺序启动,leader也会是server2, 因为在第二轮投票时 server1和server2会投给server2, 达到过半,(server3会投给自己) (集群中没有leader时每个节点优先投给自己)
如果是四台, 按顺序启动, leader会是server4, 但会有三轮选举. 在第二轮中, 每个节点的票数: server1:0 ; server:2 ; server3:1 ; server4:1
server2票数没有过半, 所以需要会发起一轮投票, 而server4的myid最大, 所以大家都会投给它,
服务器[运行]时期的Leader选举
个人简述: 集群运行过程中,leader突然宕机了,其他机器就把自己的状态变成LOOKING状态,开始选举新的leader(如同新启动时的那种),但是不同的是,每个broken上的zxid可能是不同的(可能数据还未完全同步)
在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下
(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
(3) 接收来自各个服务器的投票。与启动时过程相同。
(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。
(5) 统计投票。与启动时过程相同。
(6) 改变服务器的状态。与启动时过程相同。
参考: