zookeeper leader选举

zookeeper选举算法

• zookeeper有三种算法来实现leader选举：
  1. LeaderElection算法
  2. AuthFastLeaderElection算法
  3. FastLeaderElection算法.

具体使用哪种算法,可以在配置文件中配置,对应的配置项是electionAlg,
配置值分别对应以上序号，默认使用FastLeaderElection算法，本文仅以默认算法流程；

leader 选举

选举属性：

• 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

选举源码类：

FastLeaderElection,实现Election接口的lookForLeader方法，从类关系上来看，AuthFastLeaderElection，LeaderElection这两个实现类已经被废弃，目前仅剩FastLeaderElection这个实现类；

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