如何在zookeeper集群中选举出一个leader,zookeeper使用了三种算法,具体使用哪种算法,在配置文件中是可以配置的,对应的配置项是”electionAlg”,其中1对应的是LeaderElection算法,2对应的是AuthFastLeaderElection算法,3对应的是FastLeaderElection算法.默认使用FastLeaderElection算法，此处仅以默认算法流程；

     首先了解几个属性：       electionEpoch：每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次       peerEpoch：每次leader选举完成之后，都会选举出一个新的peerEpoch，用来标记事务请求所属的轮次       serverID：配置文件中配置的每个服务器对应的ID       zxid:为了保证事务一致性，zk采用了递增的事务ID号（zxid）来标识事务。所有的提议都在呗提出的时候加上了zxid。实现中，zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的peerEpoch，标识当前属于那个leader的通知时期，低32位用于递增计数；      选举状态：           Looking: 当前server不知道leader是谁，正在搜寻           Following:leader已经选举出来，当前server与之同步           Leading:当前server即为选举出来的leader           Observing:大多数行为与following一致，但是不参加选举，只接受选举的结果

   选举发送内容：

     serverID，zxid,peerEpoch，当前选举状态；

   选举流程：

     1.每个服务器都发送自己选举的leader，首轮会发送的选票都会投给自己；      2.服务器收到其他服务器的选票：       收到的推荐人是looking状态：        首先判断逻辑时间：          (1) 收到的选票逻辑时间大于目前的逻辑时钟，则说明选举已经进入新一轮了，所以需要更新本机逻辑时间，并清空之前收到的选票信息；然后更新选票信息，广播出去；          (2) 收到的选票逻辑时间等于目前的逻辑时钟，则判断是否需要更新推荐人，如更新，则广播出去；         然后记录选票信息，本地进行选举，如选举出来，则等待一段时间没有新的选票后，则进行角色确认，更改状态返回最终选票；       收到的推荐人是following、leading状态：        (1)  收到的选票逻辑时间等于目前的逻辑时钟，进行本地选举，并确定收到的选票为leader，如果确定，则进行角色确认，返回最终选票        (2)  如果上一步没有确定角色且返回最终选票，则将选票存入outofelection中，进行再次选举，如果能确定出leader，且确定收到的选票为leader，如果确定，则进行角色确认，返回最终选票；   流程图：           选举判定：        依次判定peerEpoch,zxid,serverId                    选举源码类：       FastLeaderElection,实现Election接口的lookForLeader方法，从类关系上来看，AuthFastLeaderElection，LeaderElection这两个实现类已经被废弃，目前仅剩FastLeaderElection这个实现类；       

 以上为最近根据源码及网上资料总结，总结的过程中可以使自己的理解更深刻，

 

 

   参考资料：