zookeeper之leader选举过程

关于leader选举会分为两个过程：

1.启动时leader的选举

2.leader崩溃时的选举

一

在每个节点刚启动的时候，状态都是Locking状态，然后就会开始选举的流程，因为leader选举至少需要两台服务器，所以一般会选举三台组成服务器集群。当第一台服务器刚启动的时候，它自己是无法进行和完成leader选举的，等待第二台服务器启动的时候，两台机器才可以相互通信。每台机器都试图找到leader，就进入leader的选举过程。

1.每一个服务器都会发起一个投票，由于刚开始第一轮启动，所以都会选择自己。然后生成一个(myid,Zxid.epoch)消息,epoch为0，zxid也为0.此时假设服务器A先启动，则消息为(1,0),服务器B生成的消息为(2,0),然后将投票发给急群中的其他机器

2.接收来自其他各个服务器上的投票。集群中各个服务器接收到投票后，会先判断该投票的有效性，先检查版本是否本轮投票、是否来自Lock状态的服务器。

3.处理该投票。先比较其他服务器的投票与自己的，比较顺序为:

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

对于 Server1 而言，它的投票是(1, 0)，接收 Server2的投票为(2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为(2, 0)，然后重新投票。

对于 Server2 而言，它不需要更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

此时更新投票为第二轮，epoch+1

4.统计投票信息，每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了 Leader。

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

二、运行过程中的 leader 选举

当集群中的 leader 服务器出现宕机或者不可用的情况时，那么整个集群将无法对外提供服务，而是进入新一轮的Leader 选举，服务器运行期间的 Leader 选举和启动时期的 Leader 选举基本过程是一致的。

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

2.每个 Server 会发出一个投票。在运行期间，每个服务器上的 ZXID 可能不同，此时假定 Server1 的 ZXID 为123，Server3的ZXID为122；在第一轮投票中，Server1和 Server3 都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。接收来自各个服务器的投票。与启动时过程相同。

3处理投票。与启动时过程相同，此时，Server1 将会成为 Leader。

4.统计投票。与启动时过程相同。

5改变服务器的状态。与启动时过程相同.