zookeeper系列(二)

前言

在上一篇咱們講到，ZooKeeper 是一個開源的分佈式協調服務，因爲zookeeper的設計目標是用於協調分佈式系統的工做，因此其自己也須要支持集羣部署，以免分佈式系統出現單點問題。

分佈式應用程序能夠基於 ZooKeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、分佈式鎖和分佈式隊列等功能。

zookeeper的集羣介紹

在以前的集羣模式中最多見的莫過於： Master/Slave 模式（主備模式）。在這種模式中，一般 Master服務器做爲主服務器提供寫服務，其餘的 Slave 服務器從服務器經過異步複製的方式獲取 Master 服務器最新的數據提供讀服務。

例如MySQL就能夠經過設置slave服務器去讀取master的二進制日誌來進行不一樣數據庫之間的數據同步，這就是典型的master/slave模式的應用。

可是，在 ZooKeeper 中沒有選擇傳統的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。以下圖所示

集羣角色介紹

ZooKeeper 集羣中的全部機器經過一個 Leader 選舉過程來選定一臺稱爲 「Leader」 的機器，Leader 既能夠爲客戶端提供寫服務又能提供讀服務。除了 Leader 外，Follower 和 Observer 都只能提供讀服務。 Follower 和 Observer 惟一的區別在於 Observer 機器不參與 Leader 的選舉過程，也不參與寫操做的「過半寫成功」策略，所以 Observer 機器能夠在不影響寫性能的狀況下提高集羣的讀性能。

當 Leader 服務器出現網絡中斷、崩潰退出與重啓等異常狀況時，zookeeper就會進入恢復模式並選舉產生新的Leader服務器。這個過程大體是這樣的：

1. Leader election（選舉階段）：節點在一開始都處於選舉階段，只要有一個節點獲得超半數節點的票數，它就能夠當選準 leader。
2. Discovery（發現階段）：在這個階段，followers 跟準 leader 進行通訊，同步 followers 最近接收的事務提議。
3. Synchronization（同步階段）:同步階段主要是利用 leader 前一階段得到的最新提議歷史，同步集羣中全部的副本。同步完成以後 準 leader 纔會成爲真正的 leader。
4. Broadcast（廣播階段） 到了這個階段，Zookeeper 集羣才能正式對外提供事務服務，而且 leader 能夠進行消息廣播。同時若是有新的節點加入，還須要對新節點進行同步。

不一樣類型集羣的選舉機制

1. 全新集羣的選舉機制

以一個簡單的例子來講明整個選舉的過程。

假設有五臺服務器組成的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同樣，當小弟。

2. 非全新集羣的選舉機制

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

須要加入數據id、leader id和邏輯時鐘：

• 數據id：數據新的id就大，數據每次更新都會更新id。
• Leader id：就是咱們配置的myid中的值，每一個機器一個。
• 邏輯時鐘：這個值從0開始遞增，每次選舉對應一個值，也就是說: 若是在同一次選舉中，那麼這個值應該是一致的 ; 邏輯時鐘值越大，說明這一次選舉leader的進程更新.

選舉的標準就變成：

一、邏輯時鐘小的選舉結果被忽略，從新投票。

二、統一邏輯時鐘後，數據id大的勝出。

三、數據id相同的狀況下，leader id大的勝出。

根據這個規則選出leader。

總結

到這裏對於zookeeper的介紹也就差很少了，更加深層次的paxos算法和ZAB協議就不在這裏討論，待之後再說。

zookeeper的核心是 Paxos算法，可是zookeeper 並無徹底採用 Paxos算法 ，而是使用 ZAB 協議做爲其保證數據一致性的核心算法。

因此這裏咱們最後總結一下zookeeper的特性吧

zookeeper的特性

1. Zookeeper：一個leader，多個follower組成的集羣。

2. 全局數據一致：每一個server保存一份相同的數據副本，client不管鏈接到哪一個server，數據都是一致的。

3. 分佈式讀寫，更新請求轉發，由leader實施。

4. 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行到zookeeper中去。

5. 數據更新原子性，一次數據更新要麼成功，要麼失敗。全部事務請求的處理結果在整個集羣中全部機器上的應用狀況是一致的，也就是說，要麼整個集羣中全部的機器都成功應用了某一個事務，要麼都沒有應用。

6.實時性，在必定時間範圍內，client能讀到最新數據。

7. 可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。

參考自：

github.com/Snailclimb/…