zookeeper的FastLeaderElection选举算法

在zookeeper中主要有3中选举算法：

1. LeaderElection(UDP版本)
2. AuthFastLeaderElection(UDP版本，这个选举算法包含2种，1/不带授权模式的FastLeaderElection,2/带有授权模式的AuthFastLeaderElection)
3. FastLeaderElection(TCP版本)
   配置选举算法：
   zoo.cfg文件中配置electionAlg属性来指定
   electionAlg=0 #使用UDP版本的LeaderElection
   electionAlg=1 #使用非授权模式的FastLeaderElection
   electionAlg=2 #使用授权模式的AuthFastLeaderElection
   electionAlg=3 #使用TCP版本的FastLeaderElection
   在zookeeper 3.4.0版本后已经废除了前2种选举算法，只支持TCP版本的FastLeaderElection算法。

• FastLeaderElection算法流程：
  半数以上算法：(n/2+1)
  前提3台机器顺序启动：
  server1(myid=1),server2(myid=2),server3(myid=3)

1. 第一台机器server1启动后，发现集群中还没有leader服务器，则向集群中发出leader选举，第一次先推荐自己，会将自己的sid和zxid和epoch发送出去，记作(epoch,sid,zxid)的形式为投票信息发送，其中epoch为一个逻辑时钟，标识leader选举的轮次，每一轮选举都会对epoch进行叠加(直接加1操作)。
2. 由于目前集群中只启动了1台机器，所以server1无法得到集群半数以上的机器同意。所以此时的server1的状态为LOOKING状态。
3. 第二台机器server2启动后，会也首先推荐自己为leader，并像server1的那样将(epoch,sid,zxid)的投票消息发送出去，在每台机器会有接受线程和发送线程来进行处理，这时server1会收到server2发出的推荐消息(epoch,sid,zxid)，server1收到消息后和自己推荐的(此时server1推荐的是自己)进行判断，判断条件：
   1、如果epoch的轮次比自己大，则更新推荐变更，将自己推荐的为这个最新的epoch的投票并向集群的其他机器发送出去。
   2、如果epoch比自己写，则忽略，并坚持自己的投票，将投票信息发送出自己的投票信息到其他机器。
   3、如果epoch相等，则判断zxid，如果zxid比自己大，则变更投票为这个收到的投票，并将变更后的投票发送给集群其他机器。
   4、如果zxid比自己小，则坚持自己的投票，将投票信息发送给集群其他的机器。
   5、如果zxid相等，则判断sid，如果sid比自己小，则坚持自己的投票，并将变更后的投票发送给集群其他的机器。
   5、如果sid比自己大，则变更投票，并将变更后的投票发送到集群其他的机器上。
   4、server1收到server2发送的投票信息后，判断后比自己大（先判断epoch，在判断zxid，最后判断sid，由于是首次启动，所以前面的spoch和zxid都是一样的，只有sid小），会变更投票为server2推荐的，server2推荐的是server2自己，所以这个时候server2会等到2票(server1和server2)，已经超过半数以上，所以server2会成为leader。
   5、当server3启动的时候，也会向集群中发送投票leader，由于前面已经有server2成为了leader，所以，server3的sid虽然是最大的，但是已经存在了leader，则不会再此进行选举，所以server3会成为follower。
   6、server2由于故障挂掉后进行重新选举，选举和前面的算法是一样的，只是这个时候的zxid就不一定是一致的。