簡介：

ZooKeeper：為分散式應用提供了高效且可靠的分散式協調服務，提供了諸如統一命名服務、配置管理和分散式鎖等分散式的基礎服務。

Zookeeper介紹：

是一個開放原始碼的分散式協調服務，設計目標是將那些複雜且容易出錯的分散式一致性服務封裝起來，構成一個高效可靠的原語集，並以一系列簡單易用的介面提供給使用者使用。

ZooKeeper是什麼：

是一個典型的分散式資料一致性的解決方案，分散式應用程式可以基於它實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master選舉、分散式鎖和分散式佇列等功能。ZooKeeper可以保證如下分散式一致性特性：

• 順序一致性
• 原子性
• 單一檢視（Single System Image）
• 可靠性
• 實時性

ZooKeeper的設計目標：

致力於提供一個高效能、高可用，且具有嚴格的順序訪問控制能力（主要是寫操作的嚴格順序性）的分散式協調服務。高效能使得ZooKeeper能夠應用於那些對系統吞吐有明確要求的大型分散式系統中，高可用使得分散式的單點問題得到了很好的解決，而嚴格的順序訪問控制使得客戶端能夠基於ZooKeeper實現一些複雜的同步原語。

四個設計目標：
1、 簡單的資料模型：通過一個共享的、樹型結構的名字空間來進行相互協調。名字空間由一系列ZNode的資料節點組成，資料模型類似於一個檔案系統，而ZNode之間的層級關係，就像檔案系統的目錄結構一樣。
2、 可以構建叢集：ZooKeeper的客戶端程式會選擇和叢集中任意一臺機器共同來建立一個TCP連線，而一旦客戶端和某臺ZooKeeper伺服器之間的連線斷開後，客戶端會自動連線到叢集中的其它機器。
3、 順序訪問：對於來自客戶端的每個更新請求，ZooKeeper都會分配一個全域性唯一的遞增編號，這個編號反應了所有事務操作的先後順序。
4、 高效能：ZooKeeper將全亮資料儲存在記憶體中，一次來實現提高伺服器吞吐、減少延遲的目的。

ZooKeeper的基本概念

叢集角色：

最典型的叢集模式就是Maste/Slave（主備模式）。在這種模式中，能夠處理所有寫操作的機器就是Master機器，把所有通過非同步複製方式獲取最新資料，並提供讀服務的機器成為Slave機器。

但是ZooKeeper沒有沿用傳統的Master/Slave概念，而是引用了Leader、Follower和Observer三種角色。

• Leeder伺服器提供讀和寫服務。

• Follower和Observer都能提供讀服務，唯一的區別在於，Observer機器不參與Leader選舉過程，也不參與寫操作的“過半寫成功”策略，因此Observer可以不影響寫效能的情況下提升叢集的度效能。

會話（Session）：

指的是客戶端會話，在ZooKeeper中，一個客戶端連線是指客戶端和伺服器之間的一個TCP長連線。對外的預設埠是2181，客戶端啟動的時候，首先會與伺服器建立一個TCP連線，通過這個連線，客戶端能夠通過心跳檢測與伺服器保持有效的會話，也能夠向ZooKeeper伺服器傳送請求並接收響應，同時還能通過該連線接收來自伺服器的Watch事件通知。

資料節點（ZNode）

有兩種型別，第一種是指構成叢集的機器，稱之為機器節點；第二種是指資料模型中的資料單元。

ZNode分為持久節點和臨時節點兩類。持久節點是指一旦這個ZNode被建立了，除非主動進行ZNode的移除操作，否則這個Znode將一直儲存在ZooKeeper上。而臨時節點它的生命週期和客戶端的會話繫結，一旦客戶端會話失效，那麼這個客戶端建立的所有臨時節點都會移除。

另外，ZooKeeper還允許使用者為每個節點新增一個特殊的屬性：SEQUENTIAL。一旦節點唄標記上這個屬性，那麼在這個節點被建立的時候，ZooKeeper會自動在其節點後面追加一個整型數字，這個整型資料就是一個由父節點維護的自增數字。

版本（Version）

ZooKeeper的每個ZNode上都會儲存資料，對應於每個ZNode，ZooKeeper都會為其維護一個叫做Stat的資料結構，Stat中記錄了這個ZNode的三個資料版本，分別是version（當前ZNode的版本），cversion（當前ZNode的子節點的版本）和aversion（當前ZNode的ACL版本）。

Watcher（事件監聽器）

zooKeeper允許使用者在制定節點上註冊一些Watcher，並且在一些特定時間觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去。

ACL（Access Control Lists）有以下五種許可權

• CREATE：建立子節點的許可權

• READ：獲取節點資料和子節點列表的許可權
• WRITE：更新節點資料的許可權
• DELETE：刪除子節點的許可權
• ADMIN：設定節點的ACL的許可權

ZAB協議

ZooKeeper採用了*ZooKeeper Atomic Broadcast（ZAB，ZooKeeper源自訊息廣播協議）*作為其資料一致性的核心演算法

支援崩潰回覆的原子廣播協議。依賴ZAB協議來支援叢集中個副本之間資料的一致性。

具體的，ZooKeeper使用一個丹儀的主程序來接收並處理客戶端的所有事務請求，並採用ZAB的原子廣播協議，將伺服器資料的狀態變更以事務Proposal的形式廣播到所有的副本程序上去。

ZAB協議的這個主備模式架構保證了同一時刻叢集中只能夠有一個主程序來廣播伺服器的狀態變更，因此能夠很好地處理客戶端大量的併發請求。

ZAB兩種基本的模式

1、崩潰恢復

當整個服務框架在啟動過程中，或是當Leader伺服器出現網路終端、崩潰退出與重啟等異常情況時，ZAB協議就會進入恢復模式並選舉產生新的Leader伺服器。當選舉產生了新的Leader伺服器，同時叢集中已經有過半的機器與該Leader伺服器完成了狀態同步之後，ZAB協議就會退出恢復模式。（狀態同步指的是資料同步）

當叢集中已經有過半的Follower伺服器完成了和Leader伺服器的狀態同步，那麼整個服務框架就可以進入訊息廣播模式。

2、訊息廣播

訊息廣播過程使用的是一個源自廣播協議，類似於一個二階段提交過程。

針對客戶端的事務請求，Leader伺服器會為其生成對應的事務Proposal，並將其傳送給叢集中其餘所有的機器，然後再分別收集各自的選票，最後進行事務提交

整個訊息廣播協議是基於具有FIFO特性的TCP協議來進行網路通訊的，因此能夠很容易地保證訊息廣播過程中訊息接收和傳送的順序性。

總結：ZAB協議規定了如果一個事務Proposal在一臺機器上被處理成功，那麼應該在所有的機器上都被處理成功，哪怕機器出現故障崩潰。ZAB協議需要確保那些已經在Leader伺服器上提交的事務最終被所有伺服器都提交。

深入ZAB協議

系統模型

如果一個程序正常工作，那麼我們稱該程序處於UP狀態；如果一個程序崩潰了，那麼我們稱其處於DOWN狀態。

事實上，當叢集中存在過半的處於UP狀態的程序組成一個程序子集之後，就可以進行正常的訊息廣播了。這樣的子集稱為Quorum。

P1和P2分別代表程序組中的兩個不同程序，使用C12來表示程序P1和P2之間的網路通訊通道，其滿足如下兩個基本特性：

1、完整性（Integrity）
2、前置性（Prefix）

問題描述

規定了任何時候都需要保證只有一個主程序負責進行訊息廣播，而如果主程序崩潰了，就需要選舉一個新的主程序。主程序的選舉機制和訊息廣播機制是緊密相關的。

主程序週期

為了保證主程序每次廣播出來的事務訊息都是一致的，必須確保ZAB協議只有在充分完成崩潰恢復階段之後，新的主程序才可以開始新的事務訊息廣播。假設各個程序都實現類似於ready(e)這樣的一個函式呼叫，在執行過程中，ZAB協議能夠非常明確地告知上層系統是否可以開始進行事務訊息的廣播。

事務

假設存在類似於transaction(v,z)這樣的函式呼叫，來實現主程序對狀態變更的廣播。

主程序每次對transaction(v,z)函式的呼叫都包含了兩個欄位：事務內容v和事務標緻z，而每一個事務標緻z=<e,c>也包含了兩個組成部分，前者是主程序週期e，後者是當前主程序週期內的事務計數c。

針對每一個新的事務，主程序都會首先將事務計數遞增。

演算法描述

細分為三個階段：
1、發現（discovery）：
2、同步（Synchronization）
3、廣播（Broadcast）

執行分析

每一個程序都有可能處於以下三種狀態之一：
1、LOOKING：Leader選舉階段
2、FOLLOWING：Follower伺服器和Leader保持同步狀態
3、LEADING：Leader伺服器作為主程序領導狀態