前言
半數機制（Paxos 協議）：集群中半數以上機器存活，集群可用。所以zookeeper適合裝在奇數台機器上。
Zookeeper雖然在配置文件中並沒有指定master和slave。但是，zookeeper工作時，是有一個節點為leader，其他則為follower，Leader是通過內部的選舉機制臨時產生的
第一次啟動選舉機制
假設有五台服務器組成的zookeeper集群，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史數據，在存放數據量這一點上，都是一樣的。假設這些服務器依序啟動，來看看會發生什么。
（1）服務器1啟動，此時只有它一台服務器啟動了，它發出去的報沒有任何響應，所以它的選舉狀態一直是LOOKING狀態。（由於人都是自私的，機器也一樣，所以服務器1先給自己投一個leader票）
（2）服務器2啟動，同樣，服務器2在啟動以后也會先給自己投一票。它與最開始啟動的服務器1進行通信，互相交換自己的選舉結果，由於兩者都沒有歷史數據，並且server2的id比server1大，所以id較大的服務器2勝出，但是由於沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3)，所以服務器1、2還是繼續保持LOOKING狀態。
（3）服務器3啟動，根據前面的理論分析，服務器3成為服務器1、2、3中的老大，而與上面不同的是，此時有三台服務器選舉了它，所以它成為了這次選舉的leader。
（4）服務器4啟動，根據前面的分析，理論上服務器4應該是服務器1、2、3、4中最大的，但是由於前面已經有半數以上的服務器選舉了服務器3，所以它只能接收當小弟的命了。
（5）服務器5啟動，同4一樣當小弟。
這里有幾個需要注意的概念：
SID：服務器ID。用來唯一標識一台ZooKeeper集群中的機器，每台機器不能重復，和myid一致。
ZXID：事務ID。ZXID是一個事務ID，用來標識一次服務器狀態的變更。在某一時刻，集群中的每台機器的ZXID值不一定完全一致，這和ZooKeeper服務器對於客戶端"更新請求"的處理邏輯有關。
Epoch：每個Leader任期的代號。沒有Leader時同一輪投票過程中的邏輯時鍾值是相同的。每投完一次票這個數據就會增加
非第一次啟動選舉機制
總的來說，可以將選舉機制想象成公司選領導。第一次選領導時，大家的資歷、掌握的技術都相同，此時可以將每個人的年齡看做選舉條件，誰的年齡大就選誰當領導。經歷一段時間之后，這個領導辭職了，沒有領導了，這時候又要繼續選領導。此時就先看誰之前當過領導，當過領導的直接商人。如果大家都沒當過，或者有多個人都當過領導，就看誰平常干的事多，誰的貢獻更大就選誰當領導。如果出現相同的情況，就再根據年齡選領導，誰大選誰。