zookeeper的leader选举过程

参考： 《从paxos到Zookeeper分布式一致性原理与实践》

（1）首先设置状态为LOOKING，初始化内部投票Vote (id,zxid) 数据至内存，并将其广播到集群其它节点。节点首次投票都是选举自己作为leader，将自身的服务ID、处理的最近一个事务请求的ZXID（ZXID是从内存数据库里取的，即该节点最近一个完成commit的事务id）及当前状态广播出去。然后进入循环等待及处理其它节点的投票信息的流程中。
（2）循环等待流程中，节点每收到一个外部的Vote信息，都需要将其与自己内存Vote数据进行PK，规则为取ZXID大的，若ZXID相等，则取ID大的那个投票。若外部投票胜选，节点需要将该选票覆盖之前的内存Vote数据，并再次广播出去；同时还要统计是否有过半的赞同者与新的内存投票数据一致，无则继续循环等待新的投票，有则需要判断leader是否在赞同者之中，在则退出循环，选举结束，根据选举结果及各自角色切换状态，leader切换成LEADING、follower切换到FOLLOWING、observer切换到OBSERVING状态。 

算法细节可参照FastLeaderElection.lookForLeader()，主要有三个线程在工作：选举线程（主动调用lookForLeader方法的线程，通过阻塞队列sendqueue及recvqueue与其它两个线程协作）、WorkerReceiver线程（选票接收器，不断获取其它服务器发来的选举消息，筛选后会保存到recvqueue队列中。zk服务器启动时，开始正常工作，不停止）以及WorkerSender线程（选票发送器，会不断地从sendqueue队列中获取待发送的选票，并广播至集群）。WorkerReceiver线程一直在工作，即使当前节点处于LEADING或者FOLLOWING状态，它起到了一个过滤的作用，当前节点为LOOKING时，才会将外部投票信息转交给选举线程处理；如果当前节点处于非LOOKING状态，收到了处于LOOKING状态的节点投票数据（外部节点重启或网络抖动情况下），说明发起投票的节点数据跟集群不一致，这时，当前节点需要向集群广播出最新的内存Vote(id，zxid)，落后节点收到该Vote后，会及时注册到leader上，并完成数据同步，跟上集群节奏，提供正常服务。

1. leader选举算法

 FastLeaderElection.lookForLeader()

2. 事务Id （ZXID）

64位， 高32位为集群选举周期，默认为0，每选举一次就加1，低32位表示该事务在当前选择周期内的递增次序

3.  工作线程

1） 选举线程  （判断是否过半，若没有，则获取接收队列中选票，PK后，若外部获胜，则将选票加入发送队列）

2） 选票接收器（不断获取其他follower发来的选举消息，筛选后保存到接收队列中）

3） 选票发送器  （不断地从发送队列中获取待发送的选票，并广播到集群）