Zookeeper中的FastLeaderElection選舉算法簡述
Zookeeper的基本前提是多個節點都具備全局其他全部節點的基本信息（IP/port/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的平方。
不知我的理解是否正確。希望有高手指正。Zookeeper中的FastLeaderElection選舉算法簡述