[TOC] # 簡介 Zookeeper雖然在配置文件中并沒有指定master和slave 但是，zookeeper工作時，是有一個節點為leader，其他則為follower Leader是通過內部的選舉機制臨時產生的 # zookeeper的選舉機制（zk的數據一致性核心算法paxos） 以一個簡單的例子來說明整個選舉的過程. 假設有五臺服務器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啟動,來看看會發生什么. 1) 服務器1啟動,此時只有它一臺服務器啟動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態 2) 服務器2啟動,它與最開始啟動的服務器1進行通信,互相交換自己的選舉結果,由于兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由于沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態 3) 服務器3啟動,根據前面的理論分析,服務器3成為服務器1,2,3中的老大,而與上面不同的是,此時有三臺服務器選舉了它,所以它成為了這次選舉的leader. 4) 服務器4啟動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,但是由于前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了 5) 服務器5啟動,同4一樣,當小弟. # 非全新集群的選舉機制(數據恢復) 那么，初始化的時候，是按照上述的說明進行選舉的，但是當zookeeper運行了一段時間之后，有機器down掉，重新選舉時，選舉過程就相對復雜了。 需要加入數據version、leader id和邏輯時鐘。 數據version：數據新的version就大，數據每次更新都會更新version。 Leader id：就是我們配置的myid中的值，每個機器一個。 邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值,也就是說: ?如果在同一次選舉中,那么這個值應該是一致的 ; ?邏輯時鐘值越大,說明這一次選舉leader的進程更新. 選舉的標準就變成： 1. 邏輯時鐘小的選舉結果被忽略，重新投票 2. 統一邏輯時鐘后，數據id大的勝出 3. 數據id相同的情況下，leader id大的勝出 根據這個規則選出leader。