zookeeper的选举机制：
当leader崩溃或者leader失去太多的followler，这时zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都回复到一个正确的状态，zk有两种选举算法：一种基于basic paxos实现的，另外一种是基于fase paxos算法实现的，默认的选举算法为fast paxos
fast paxos：
1、服务器启动时的leader选举
若进行leader选举，则至少需要两台机器，这里选取三台服务器组成的集群为例。在集群初始化阶段，当有一台服务器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，此时sercer2的myid最大，于是更新自己的投票为（2，0），然后重新投票，对于server2而言，其无需更新自己的投票，只是再次想集群中所有的机器发出上一次投票信息即可。
<4>统计投票。每次投票后，服务器都会统计投票信息，判断是否已经哟过半机器接收到相同的投票信息，对于server1、server2而言，都统计处集群中已经有两台机器接收了（2，0）的 投票信息，此时便认为已经选出了leader
<5>改变服务器状态，一旦确定了leader，每个服务器就会更新自己的状态，如果是follower，那么久变更为following，如果是leader，就变更为leading
当zoo.cfg文件中配置了两台服务器时，启动两台服务器的zk就可以选举出leader，第二个启动的server为leader
当zoo.cfg文件中配置了三台服务器时，启动两台服务器的zk就可以选举出leader，第二个启动的server为leader
当zoo.cfg文件中配置了四台服务器时，必须启动三台服务器的zk才可以选举出leader，第二个启动的server为leader
以下为本人对zk的选举机制做的一些小实验：
步骤：先启动hadoop04--->hadoop03--->hadoop02--->hadoop01
leader:hadoop03
follower:hadoop04,hadoop02,hadoop01
kill hadoop04
hadoop01,hadoop02,hadoop03状态不变
kill hadoop01
hadoop02异常（集群崩溃）
hadoop03异常（集群崩溃）
重新启动hadoopo04
leader：hadoop03
follower:hadoop04,hadoop02
启动hadoop01
状态不变
kill hadoop03
leader：hadoop01
follower:hadoop02,hadoop04
启动hadoop03
kill hadoop01
leader:hadoop03
启动hadoop01
kill hadoop03
leader hadoop01
其余为follower
从上述实验可以得出结论，当zookeeper配置超过三台机器时，
第一次启动集群时，leader为第二个启动的机器，其他为follower，符合上述理论
当第二台机器挂掉后，最后一台机器成为leader。
此时若第二台机器恢复，则会成为follower，若此时leader挂掉，则第二台机器成为leader。
当最后一台机器挂掉后，倒数第二台机器成为leader。
