zookeeper leader选举

     如何在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这个实现类；
      

 以上为最近根据源码及网上资料总结，总结的过程当中可使本身的理解更深入，
 

 
   参考资料： 
    http://codemacro.com/2014/10/19/zk-fastleaderelection/ 
    http://http://www.cnblogs.com/leesf456/p/6508185.html 
    http://blog.jobbole.com/107583/