1、Zookeeper選舉機制

Zookeeper雖然在配置檔案中並沒有指定master和slave

但是，zookeeper工作時，是有一個節點為leader，其他則為follower

Leader是通過內部的選舉機制臨時產生的

9.1 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一樣,當小弟.

9.2 非全新叢集的選舉機制(資料恢復)

那麼，初始化的時候，是按照上述的說明進行選舉的，但是當zookeeper運行了一段時間之後，有機器down掉，重新選舉時，選舉過程就相對複雜了。

需要加入資料version、leader id和邏輯時鐘。

資料version：資料新的version就大，資料每次更新都會更新version。

Leader id：就是我們配置的myid中的值，每個機器一個。

邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值,也就是說:  如果在同一次選舉中,那麼這個值應該是一致的 ;  邏輯時鐘值越大,說明這一次選舉leader的程序更新.

選舉的標準就變成：

                  1、邏輯時鐘小的選舉結果被忽略，重新投票

                  2、統一邏輯時鐘後，資料id大的勝出

                  3、資料id相同的情況下，leaderid大的勝出

根據這個規則選出leader。