1. 前言
在Zookeeper集群环境中，不同机器中的数据一致性是很重要的一环，要保证数据的一致性，Leader选举必不可少。
①. 在哪些情况下会触发Leader选举
-
服务器启动的时候
-
在运行期间，Leader挂掉的时候。
2. 服务器启动期间的选举
Leader选举的时候，必须要在两台服务器以上，我们以三台为例，分别是server1，server2，server3。
这时先启动server1，由于只有一台服务器启动，不能满足选举，所以不会进行Leader的选举。接着启动server2，这两台服务器之间就开始通信，于是就开始了Leader的选举。
①. 每个server都会发出投票
初始情况下，server1，server2都会将自己作为Leader来进行选举，并向其他服务器发送自己的投票，每次投票都会包含自己投票机器的myid和zxid，[myid，zxid]，假设server1此时的投票信息为[1,123]，server2此时的投票信息为[2,123]。然后他们各自将自己的投票信息发送给其他服务器。
②. 接收来自其他服务器的投票，并检查
接收到来自其他服务器的投票后，先判断投票的有效性，检查zxid，判断是否是本轮投票，判断是否来自looking服务器的投票（looking是正在试图选举出一个leader的状态）。
③. 处理投票，与自己投票进行pk
集群中，每个服务器收到投票后，都会与自己的投票进行pk，pk的基本顺序如下：
-
检查zxid，zxid大的直接选举为leader
-
zxid相同，比较myid，myid大的选举为leader
这里对于server1(1,123),server2(2,123),由于zxid都是123，则进行第二步，选举了server1就更新自己的投票为(2,123)。serve2r比较，发现自己的myid大，则不作变更
④. 投票统计
每次投票后，服务器都会进行投票统计投票信息，判断是否已有过半的机器收到了相同的投票，对于server1，server2而言，两台投票信息都是（2，123），满足过半机制。便认为已经选出了Leader。
⑤. 更新服务器状态
由于已经选举到了Leader，每个服务器都会变更自己的状态，server1改为Follower，server2改为Leader
3. Leader挂掉后的Leader重选
在Zookeeper运行期间，每个服务器各司其职，此时就算有新的服务器加入进来，也不会影响到Leader，但是一旦有Leader挂了，此时暂停对外服务，或者Follower挂了导致，进入新的一轮选举，这个过程基本与第一轮一致。目前三台机器，server2是Leder，挂了，开启重新Leader选举。
leader挂了过后。
①. 变更服务器状态。
leader挂后，服务器变更状态为looking，然后进入leader选举过程，此时服务器开启只读模式让服务器读取数据。
②. 每个服务器发起投票
此过程与第一次相同，由于在运行期间，可能每个服务器的zxid不相同，这里定server1为123，server3为122，在投票过程中，server1和server3都会投自己，分别产生[1，123],[3,122]的投票，然后各自将投票发送给其他服务。
③. 接收来自其他服务器的投票，此过程与上面启动过程一致 。
④. 处理投票，与启动过程一致。
⑤. 统计投票，与启动过程一致。
由于投票出来的结果都是server，则server1位leader，server3位Follower。
⑥. 变更服务器状态，与启动过程一致。
4. 总结
本篇仅仅大致演示了一下Leader选举的过程。由于在集群环境中，只有选举出来了Leader，整个服务才是可用的，后面的数据一致性才有了保障的前提。
来源：oschina
链接：https://my.oschina.net/u/3553496/blog/3188638