服务器启动时的leader选举
每个节点启动的时候状态都是LOOKING，处于观望状态，接下来就开始进行选举流程。
以3台机器组成的服务器集群为例，在集群初始化阶段，当有一台服务器Server1启动时，它本身是无法进行和完成Leader选举，当第二台服务器Server2启动时，这个时候两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下：
1》每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含服务器的myid和ZXID、epoch，使用(myid, ZXID,epoch)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
2》接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自LOOKING状态的服务器。
3》处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下：
1>优先检查ZXID。ZXID比较大的服务器优先作为Leader。（ZXID里，优先检查epoch，在检查ZXID。）
2>如果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选举
当集群中的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》改变服务器状态。与服务器启动时过程相同。
选举比对值分析
zxid：zxid（64位）又称事务id，它如果最大，那么会成为leader。它越大，数据也越新。
myid：服务器id，又称sid。它如果越大，在leader选举机制中权重越大。
epoch：属于zxid里的高32位，每一轮leader选举投票，它都会递增。