Zookeeper中的FastLeaderElection算法

       我们知道，在经典的paxos算法中每一个peer都是proposer，但是这就不可避免的产生提案冲突，为了减少这种冲突带来的系统消耗与时间延迟，就产生了Leader这个角色，整个系统中，就只允许Leader可以发出提案。ZooKeeper就是按照这个思路来实现的。本文主要讨论ZooKeeper中的FastLeaderElection算法,来讲解Leader是如何产生的。

    Zookeeper中的每一个peer在绝大多数情况下是共用同一个配置文件的，所以每一个peer得到的其他peer的信息(编号、ip地址、选举端口号)是一样的。Zookeeper系统启动之后，在为客户提供服务之前，是必须要产生一个Leader的。所以就必须先要执行选举Leader算法。

    在每一个peer的选举算法开始之后，默认采用FastLeaderElection算法，每一个peer一方面向所有的peer发送一张自己的选票，同时另一方面它也接受其他peer发送过来的选票，然后不停的统计票数。当然在此之前，每一个peer都会创建一个Listener来监听自己的端口号，以此来接受所有peer发送过来的选票。从这一个过程中，实际上是每一个peer都是coordinator。这样每一个peer都是coordinator话，系统就会产生n*n个网络连接，无疑消耗了大量的系统资源。但是ZooKeeper从中也是做过一些优化工作的。

    首先，每一个节点在发送选票之前都会判断这张选票是否是发送给自己的，如果是则直接存入统计选票的集合中，而不会通过网络连接发送给自己。

    其次，每一个peer节点只接受编号比自己大的peer的网络连接请求，这样产生的网络连接数就是(n-1)*(n-1)/2。

   

    另外，这个Leader的选举过程中是不会发生活锁的。因为在每一轮投票之后，每一个peer都会产生一张新选票，而每一个peer产生一张新选票的决策规则(peer数据版本号+编号)是一样的，同时这个决策规则依赖的节点数据更新程度和节点编号在任何两个peer之间是不可能重复的。

    最后，我还想再补充一点的就是统计票数问题。ZooKeeper采用了一个高度抽象的表决器(QuorumVerifier)。例如，这个表决器可以仅仅只依赖票数，也可以依赖(票数+选票权重)，等...决策策略。