Zookeeper中的FastLeaderElection选举算法简述

Zookeeper是一个开源的分布式应用协调项目， 其中为了保证各节点的协同工作，Zookeeper在工作时需要有一个Leader， 而Leader是如何被选举出来的？Zookeep中使用的缺省算法称为FastLeaderElection。

Zookeeper的基本前提是多个节点都具备全局其它所有节点的基本信息（IP/端口/SID），而SID是节点的唯一编号。正常工作时”从节点“会从“主节点”(Leader)同步版本信息，称为zxid。 

一旦整个系统重启或某部分节点(特殊是Leader)重启时，就需要重新选举Leader。

Leader选举算法的核心就是任何节点都与其它节点交换信息（通过tcp连接），通过一系列迭代，最终确定某一个受到大多数（>N/2）节点推荐的Leader。所谓推荐是根据zxid(优先)和sid值更大则推荐之。

节点启动时，先是推荐自己，然后与其它所有节点尝试建立连接，Zookeeper保证两个节点只保持一个tcp连接，因为tcp连接是双工的，所有一个连接足矣。所有的节点间通信可以理解成为异步方式。节点在发送信息给其它节点时无需等待对方处理结果，这与类似http的request/response模式是不同的。　

本节点在选举阶段(Looking状态)维持有一个推荐Leader节点(初始值是自己)，之后便是进入循环，就是接收所有任何其它节点的信息(如: SID/zxid/推荐Leader节点)，然后根据这些信息调整本节点保持的”推荐Leader节点“，一旦该值发生变化，即发送该信息给所有其它节点(广播），该循环会持续到自己或其它节点确定出Leader，即上面提到的受到大多数节点推荐的即为Leader。

进一步思考：感觉这种算法在节点数很多的情况下会有非常多的消息交互, 假设是Ｎ个节点，最坏的情况下，一个节点要经过N-1次迭代(推荐Leader节点有变化），每次迭次要发N-1个消息，　所以发送消息达N-1的平方。

不知我的理解是否正确，希望有高手指正。