在理解zookeeper選舉機制時需要先了解以下幾個概念
1.Sid (又稱服務器id,也就是zookeeper中的myid)
2.Zxid 每次znode狀態發生改變該值都會受到更新（遞增且唯一,唯一是相對於某個zk服務器而言）,每個znode其實都維護了3個zxid
| cZxid | 該節點創建時的事務id |
| mZxid | 該節點修改時的事務id |
| pZxid | 子節點修改的事務id，子節點創建修改以及刪除都會影響該事務id |
3.epoch 邏輯時鐘,也就是當前投票輪數
4.選舉狀態
| Looking | 當前server正在選舉，等待leader被選舉出來 |
| Leading | 當前server爲leader |
| Following | 當前server爲follower |
| Observing |
跟Follower差不多，就是不參與選票過程 |
瞭解了這幾個概念就可以講一講zk的選舉機制。
zk選舉機制分爲兩種，一種是啓動時的選舉,一種是zk恢復模式選舉.
我們先來將一下啓動時的選舉。
首先我們要明白一個事情zk選出leader的條件必須是leader節點必須獲得n/2+1的選票才行，n就是zk集羣的server數.
每個zk啓動時都會發起新的投票，並在這一輪投票中投票給自己。接收到別的投票時會和自己的投票進行pk。pk規則爲 判斷sid大小，推薦sid大的那個zk爲leader。
那麼這樣是否代表sid最大的在集羣啓動時必定爲leader嗎？答案當然不是。
舉個例子，假設我們現在有5臺服務器組成的zk集羣。
首先server1啓動了，此時它投票給自己，但是就他一臺server，他的狀態自然爲Looking。
然後server2啓動了，此時他發起了新的投票，他先投票給自己,並且廣播。server1接收到了server2的投票信息，發現他的邏輯時鐘大於自己，於是自己舊的投票情況作廢，重新投票給sid大於自己的server2。此時server2獲得兩票,但是選票情況未滿足n/2+1，所以server2還是Looking。
重頭戲來了，此時server3啓動了，它發起了新一輪的投票,過程就不說了（大家可以按照server2那樣來腦補一下），結果server3獲得了3票,此時選票滿足了n/2+1，server3成爲leader,server1和2爲follower。
這個時候就算server4和5啓動了，也無濟於事了，因爲此時leader已經被選舉出來了，4和5就不會發起新的投票，直接成爲follower。
zk恢復模式選舉就是說當leader節點下線或者一半節點下線集羣就會進入恢復模式直到選出新的leader，這個時候的選舉就會映入Zxid，此時是否選舉某個server爲leader的依據便是Zxid的大小，當Zxid相同再去判斷Sid。
在文章的末尾再聊一天，爲什麼很多博客都說要zk要兩臺以上，並不是說兩臺就不能玩了,兩臺也是能選舉出leader的。只不過兩臺zk毫無可用性，隨便其中一臺宕機，集羣就不能用了。
另外建議zk節點奇數節點，爲什麼呢?當個比方吧。
3臺節點時我們的集羣容錯率爲1(允許一臺非leader節點下線),當我們將集羣數提高到4臺，此時我們的集羣容錯率還是1,因爲第二臺下線的時候也會進入恢復模式。偶數集羣並不能帶給我們比奇數集羣更多的可用性(反而無謂的添加了投票階段的支出),所以最好還是奇數集羣，如果要增加集羣的可用性建議還是添加observer節點.