Zookeeper總覽（翻譯自Zookeeper官方網站Release 3.4.11版本）

Zookeeper

• Zookeeper:一個爲分佈式應用設計的分佈式協調服務
  • Zookeeper設計目標
  • Zookeeper數據模型和層級命名空間
  • Zookeeper默認節點和臨時節點
  • Zookeeper條件更新和監視(watches)
  • Zookeeper保證(Guarantees)
  • Zookeeper簡單API
  • Zookeeper實現原理
  • Zookeeper使用
  • Zookeeper性能
  • Zookeeper可靠性
  • Zookeeper項目

---

Zookeeper:一個爲分佈式應用設計的分佈式協調服務

ZooKeeper是一款開源的分佈式應用的分佈式協調服務。它包含一個簡單的原語集，分佈式應用程序能夠基於它實現同步服務，配置維護和命名服務等。Zookeeper 設計很容易進行編程，它使用一種相似於文件系統的目錄樹結構的數據模型，以 java 方式運行，有 java 和 c 的綁定(binding)。

協調服務是很是難以被正確實現的。他們特別容易產生諸如競態條件、死鎖等錯誤。ZooKeeper背後的動機是爲分佈式應用程序減輕從零開始實現協調服務的難度。

設計目標

Zookeeper是很是簡單的。

ZooKeeper容許分佈式進程經過與標準文件系統相似組織的共享層級命名空間來相互協調。命名空間被稱爲znode的數據記錄組成，用ZooKeeper的說法，這些記錄和標準文件系統中的文件和目錄很是類似。與典型的用於存儲的文件系統不一樣，ZooKeeper數據保存在內存中，這意味着ZooKeeper能夠實現高吞吐量和低延遲。

Zookeeper的實現着重於高性能、高可用性和嚴格的順序訪問。ZooKeeper的性能方面意味着它能夠用於大型分佈式系統。可靠性方面使它不會形成單點故障。嚴格的排序意味着能夠在客戶端實現複雜的同步原語。

Zookeeper 是複製的（replicated）

就像它協調的分佈式進程同樣，Zookeeper 自身也在被稱爲「ensemble」的一組主機之間進行復制。

組成 Zookeeper 服務(Service)的每一個服務器(server)之間都必須相互瞭解對方。他們維護一個內存狀態圖，以及一個持久存儲的事務日誌和快照。只要這些服務器(servers)中大多數是可用的，整個ZooKeeper服務就是可用的。

客戶端(client)鏈接到任意一臺ZooKeeper服務器。客戶端維護一個TCP鏈接，經過它發送請求、獲取響應、獲取監視事件以及發送心跳。若是到服務器的TCP鏈接中斷，客戶端將鏈接到其餘不一樣的服務器。

Zokeeper是有順序的

ZooKeeper使用反映全部ZooKeeper事務順序的數字來標記每一個更新。後續操做可使用該次序來實現更高級別的抽象，例如同步原語。

ZooKeeper 是快速的

在應對以「讀」爲主的負載時尤爲地快速。ZooKeeper應用程序在數千臺機器上運行，而且在讀取比寫入更爲廣泛的狀況下，性能表現最佳，比例約爲10：1。

Zookeeper數據模型和層級命名空間

ZooKeeper提供的命名空間與標準文件系統很是類似。路徑是由斜槓/分隔的一系列元素。 ZooKeeper命名空間中的每一個節點都由一個路徑標識。

Zookeeper默認節點和臨時節點

與標準文件系統不一樣的是，ZooKeeper命名空間中的每一個節點均可以擁有與其相關的數據以及子節點。這就像一個文件系統中能夠存在一個文件或一個目錄。ZooKeeper被設計用來存儲相關的協調數據，如狀態信息、配置、位置信息等等，因此每一個節點上存儲的數據一般都很小，在字節(byte)到千字節(kb)範圍內。咱們使用術語znode來清楚地說明咱們正在討論ZooKeeper數據節點。

Znode 維護了一個狀態(stat)結構，其中包含了表示數據改變、訪問控制列表（ACL）改變的版本號、時間戳，可用於緩存校驗、協調更新。每當一個znode的數據發生變化，版本號就會增長。例如，每當客戶端檢索數據時，客戶端也會接收到相應數據的版本信息。

存儲在命名空間中每一個節點上的數據是以原子方式讀取和寫入的。讀取一個znode將得到其所有的數據，而寫入則替換其所有的數據。

ZooKeeper也有臨時節點的概念。當建立臨時節點的客戶端會話一直保持活動，瞬時節點就一直存在。而當會話終結時，瞬時節點被刪除。

Zookeeper條件更新和監視(watches)

ZooKeeper 支持「監視」(watches)的概念。客戶端能夠在znode上設置一個監視(watch)。當 znode改變時，監視(watch)將被觸發並移除。當監視(watch)被觸發時，當「監視」被觸發時，客戶端會收到一個描述了 znode 的變動的數據包。若是客戶端和Zookeeper服務器之間的鏈接斷開時，客戶端將會收到一個本地通知。

Zookeeper保證(Guarantees)

Zookeeper很是地快速也很是簡單。不過，因爲它的目標是做爲構建諸如「同步」這類更復雜服務的基礎，它提供了一些的一組保證：

• 順序一致性 - 來自客戶端的更改請求將會按照它們的發送的順序被應用。
• 原子性 - 更改要麼成功，要麼失敗，不會存在部分紅功、部分失敗的結果。
• 單一系統映像 - 客戶端會看到 Zookeeper 服務的相同的視圖，而不管它們連到具體哪個服務器上
• 可靠性 - 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。
• 及時性 - 客戶端看到的系統視圖在必定的時間範圍內老是最新的。

簡單的API

ZooKeeper的一個設計目標是提供一個很是簡單的編程接口。 所以，它只支持這些操做：

• create

  在（命名空間）樹的一個特定地址上建立一個節點。

• delete

  刪除一個節點。

• exists

  判斷某個路徑下是否存在該節點。

• get data

  獲取節點的數據。

• set data

  向節點寫入數據。

• get children

  檢索節點的子節點列表。

• sync

  等待數據傳播完成。

Zookeeper實現原理

ZooKeeper Components 顯示了ZooKeeper服務的高級組件。除Request Processor外，構成ZooKeeper服務的每一個服務器都複製每一個組件的副本。

replicated database是一個內存數據庫，它包含了整顆數據樹。數據寫入在應用到內存數據庫以前，會先序列化到磁盤。

每個 Zookeeper 服務器都向客戶端提供服務，客戶端鏈接到一個確切的Zookeeper服務器提交請求。讀請求從服務器數據庫的本地拷貝中獲取。改變Zookeeper服務狀態的請求、寫入請求經過一個一致性協議進行處理。

做爲協議的一部分，客戶端的全部寫入請求都被轉發到一個單獨的服務器，該服務器被稱爲 leader。而其他的服務器，被稱爲follower，從leader接收消息提案（proposal）並對消息的交付取得一致。消息層維護leader失效時的更新替換以及leader和follower之間的同步。

Zookeeper 使用自定義的原子消息協議。因爲消息層是原子的，Zookeeper能夠保證本地的複製品不會不一致。當 leader收到一個寫入請求時，它計算系統所處的狀態以及什麼時候應用寫入請求，並將此轉換爲一個事務，包含新的狀態。

使用

Zookeeper 的編程接口特地地定義得很簡單。然而，經過這些編程接口能夠更高階的操做，例如同步原語，成員分組，全部權，等等。

性能

Zookeeper 被設計爲高性能。但實際是否如此呢？在雅虎研發中心的 Zookeeper 開發團隊的研究結果代表的確如此。（參見下圖：Zookeeper 吞吐量隨讀寫比的變化）。在「讀」多於「寫」的應用程序中尤爲地高性能，由於「寫」會致使在全部的服務器間同步狀態。（「讀」多於「寫」是協調服務的典型場景。）

Zookeeper 吞吐量隨讀寫比的變化

圖「Zookeeper 吞吐量隨讀寫比的變化」 是 Zookeeper3.2 版本運行於 Dual 2Gh Xeon + 2 個 15K RPM 的 SATA 硬盤驅動器的服務器上的結果。一個驅動器用做 Zookeeper 專用的日誌設備。快照寫到操做系統驅動器。寫請求是 1K 數據的寫入而讀請求是 1K 的數據讀取。「Servers」標出了 Zookeeper Ensemble 的大小，即組成 Zookeeper 服務的服務器的數量。大約30臺其它的服務器被用做模擬客戶端。Zookeeper Ensemble 被配置爲不容許客戶端鏈接到 Leader 。

注：3.2版本的讀/寫性能相對於3.1版本之前有最多達2倍的提高。

基準測試也代表了 Zookeeper 的可靠性。圖「錯誤發生的狀況下的可靠性」展現了 Zookeeper 是如何應對各類不一樣的失效的。圖中標註的事件以下：

1. 一個 Follower 失效而後恢復。

2. 另外一個不一樣的 Follower 失效而後恢復。

3. Leader 失效。

4. 兩個 Follower 失效而後恢復。

5. 另外一個 Leader 失效。

可靠性

從這張圖中能夠獲得幾點重要的結果。首先，若是 follower 失效並快速恢復，Zookeeper 可以維持高吞吐量，儘管存在失效。但也許更重要的是，leader選舉算法使系統足夠快地恢復，避免了吞吐量的整體降低。從觀察結果來看，Zookeeper花了不到200毫秒的時間選舉出了一個新的 leader。第三，只要follower恢復，Zookeeper的吞吐量可以再次上升到剛開始處理請求時的水平。

關於ZooKeeper項目

Zookeeper 已經被成功地用在許多工業級的應用。在雅虎，Zookeeper被用做雅虎消息中間件的協調和失效恢復服務，該系統是一個高伸縮性的發佈訂閱系統，管理着成千上萬的主題複製和數據分發。Zookeeper還被用在雅虎爬蟲的抓取服務上，用於管理失效恢復。許多雅虎的廣告系統也用 Zookeeper 實現可靠的服務。