ZooKeeper 文檔（概述）

概述

• ZooKeeper：分佈式應用程序的分佈式協調服務
• 設計目標
• 數據模型和層次命名空間
• 節點和臨時節點
• 有條件的更新和守望者
• 保證
• 簡單的API
• 實現
• 使用
• 性能
• 可靠性
• ZooKeeper項目

ZooKeeper：分佈式應用程序的分佈式協調服務

ZooKeeper是一個分佈式、開源的分佈式應用協調服務，它公開了一組簡單的基元，分佈式應用程序能夠在這些基元的基礎上實現更高級別的服務，以實現同步、配置維護、組和命名，它被設計成易於編程，而且使用了一個數據模型，該數據模型採用了文件系統中常見的目錄樹結構，它在Java中運行，並同時綁定了Java和C。

衆所周知，協調服務很難作好，它們特別容易出現諸如競態條件和死鎖之類的錯誤，ZooKeeper背後的動機是減輕分佈式應用從零開始實現協調服務的責任。

設計目標

ZooKeeper是簡單的。ZooKeeper容許分佈式進程經過一個共享的層次化命名空間相互協調，這個命名空間的組織相似於標準文件系統，命名空間由數據寄存器組成 - 叫znodes，在ZooKeeper的說法 - 這些相似於文件和目錄，與爲存儲而設計的典型文件系統不一樣，ZooKeeper數據被保存在內存中，這意味着ZooKeeper能夠實現高吞吐量和低延遲。

ZooKeeper的實現很是重視高性能、高可用性和嚴格有序的訪問，ZooKeeper的性能方面意味着它能夠在大型分佈式系統中使用，可靠性方面使它避免成爲單點故障，嚴格的排序意味着能夠在客戶端上實現複雜的同步基元。

ZooKeeper是複製的。就像它協調的分佈式進程同樣，ZooKeeper自己也要在一組被稱爲集成的主機上進行復制。

組成ZooKeeper服務的服務器必須互相知曉，它們維護內存中的狀態鏡像，以及持久存儲中的事務日誌和快照，只要大多數服務器可用，ZooKeeper服務就可用。

客戶端鏈接到一個ZooKeeper服務器，客戶端維護一個TCP鏈接，經過它發送請求、獲取響應、查看事件和發送心跳，若是到服務器的TCP鏈接中斷，客戶端將鏈接到另外一個服務器。

ZooKeeper是有序的。ZooKeeper用一個反映全部ZooKeeper事務順序的數字來標記每次更新，後續操做可使用順序實現更高級別的抽象，好比同步基元。

ZooKeeper是快速的。它在「讀爲主」的工做負載中尤爲快速，ZooKeeper應用程序在數千臺機器上運行，在讀比寫更廣泛的地方運行得最好，比率約爲10:1。

數據模型和層次命名空間

ZooKeeper提供的命名空間很像標準文件系統，名稱是用斜槓（/）分隔的路徑元素序列，ZooKeeper的命名空間中的每一個節點都由一條路徑來標識。

節點和臨時節點

與標準文件系統不一樣，ZooKeeper命名空間中的每一個節點均可以擁有與之關聯的數據以及子節點，這就像有一個容許文件也能夠是目錄的文件系統，（ZooKeeper被設計用來存儲協調數據：狀態信息、配置、位置信息等，所以，存儲在每一個節點上的數據一般很小，從字節到千字節不等。）咱們使用術語znode是爲了說明咱們討論的是ZooKeeper數據節點。

Znodes維護一個stat結構，其中包括數據更改的版本號、ACL更改和時間戳，以容許緩存驗證和協調更新，每次znode的數據發生變化，版本號就會增長，例如，每當客戶機檢索數據時，它也會接收數據的版本。

在命名空間中的每一個znode上存儲的數據是原子式讀寫的，讀取獲取與znode關聯的全部數據字節，寫入替換全部數據，每一個節點都有一個訪問控制列表(ACL)，它限制誰能夠作什麼。

ZooKeeper也有臨時節點的概念，只要建立了znode的會話是活動的，這些znode就存在，當會話結束時，znode將被刪除，當你想要實現[tbd]時，臨時節點很是有用。

有條件的更新和守望者

ZooKeeper支持守望者的概念，客戶端能夠在znode上設置一個守望者，當znode發生變化時，守望者將被觸發並移除，當一個守望者被觸發時，客戶端會收到一個報文，說znode已經改變了，若是客戶端和ZooKeeper服務器之間的鏈接中斷，客戶端將收到本地通知，這些能夠用於[tbd]。

保證

ZooKeeper很是快而且很是簡單，可是，因爲它的目標是成爲構建更復雜服務（如同步）的基礎，因此它提供了一組保證。
這些都是：

• 順序一致性 - 來自客戶端的更新將按發送的順序應用。
• 原子性 - 更新要麼成功，要麼失敗，沒有部分結果。
• 單一系統映像 - 不管鏈接到哪一個服務器，客戶端都將看到相同的服務視圖。
• 可靠性 - 一旦應用了更新，它將從那時起一直持續到客戶端覆蓋更新爲止。
• 及時性 - 系統的客戶端視圖保證在必定的時間範圍內是最新的。

有關這些信息以及如何使用它們的更多信息，請參見[tbd]。

簡單的API

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

• create - 在樹中的某個位置建立節點
• delete - 刪除一個節點
• exists - 測試節點是否存在於某個位置
• get data - 從節點讀取數據
• set data - 將數據寫入節點
• get children - 檢索節點的子節點列表
• sync - 等待數據被傳播

有關這些操做的更深刻討論，以及如何使用它們實現更高級別的操做，請參閱[tbd]

實現

ZooKeeper組件顯示了ZooKeeper服務的高級組件，除了請求處理器以外，構成ZooKeeper服務的每一個服務器都複製本身的每一個組件副本。

複製數據庫是包含整個數據樹的內存數據庫，更新被記錄到磁盤上以供恢復，寫入操做在應用到內存數據庫以前被序列化到磁盤。

每一個ZooKeeper服務器服務客戶端，客戶端鏈接到一個完整服務器以提交請求，從每一個服務器數據庫的本地副本服務讀取請求，更改服務狀態的請求、寫請求，是經過一致性協議來處理的。

做爲一致性協議的一部分，全部來自客戶端的寫請求都被轉發到一個名爲leader的服務器，其餘的ZooKeeper服務器，被稱爲followers，接收來自領導者的信息建議並贊成信息傳遞，消息傳遞層負責在失敗時替換領導者，並將追隨者與領導者同步。

ZooKeeper使用自定義原子消息傳遞協議，因爲消息傳遞層是原子層，ZooKeeper能夠確保本地副本不會分散，當leader收到寫請求時，它會計算應用寫時系統的狀態，並將其轉換爲捕獲新狀態的事務。

使用

ZooKeeper編程接口很是簡單，可是經過它，你能夠實現更高階的操做，例如同步原語、組成員關係、全部權等等，一些分佈式應用程序已經使用了它：[tbd：添加來自白皮書和視頻演示的用法]如需更多資料，請參閱[tbd]。

性能

ZooKeeper被設計成具備很高的性能，但真的是這樣嗎? Yahoo!研究公司的ZooKeeper開發團隊的結果代表確實如此。（當讀寫比率變化時，請查看ZooKeeper吞吐量。）在讀多於寫的應用程序中，它的性能特別高，由於寫涉及到同步全部服務器的狀態。（讀多於寫是協調服務的典型狀況。）

隨着讀寫比率的變化，ZooKeeper的吞吐量數據是一個ZooKeeper版本3.2的吞吐量圖，該版本運行在具備雙2Ghz Xeon和兩個SATA 15K RPM驅動器的服務器上，其中一個驅動器被用做專用的ZooKeeper日誌設備，快照被寫入操做系統驅動器。寫請求是1K寫，讀是1K讀，「 Servers」表示ZooKeeper集合的大小，即組成服務的服務器數量，大約有30個其餘服務器用於模擬客戶端，ZooKeeper整體的配置是這樣的:領導者不容許與客戶端創建鏈接。

與 以前的3.1版本相比，3.2版本的r/w性能提升了~2x。

基準測試也代表它是可靠的，存在錯誤時的可靠性圖顯示部署如何響應各類故障，圖中所示的事件以下：

1. 追隨者的故障和恢復
2. 一個不一樣的追隨者的故障和恢復
3. 領導者的故障
4. 兩個追隨者的故障和恢復
5. 另外一個領導者的故障

可靠性

爲了顯示系統隨着時間的推移而出現的故障，咱們運行了一個由7臺機器組成的ZooKeeper服務，咱們運行了與之前相同的飽和基準，但此次咱們把寫的百分比保持在30%不變，那是咱們預期工做量的保守比率。

存在錯誤時的可靠性以下圖：

這是一些重要的觀察結果，首先，若是追隨者故障了而且恢復得很快，那麼ZooKeeper可以在故障的狀況下維持高吞吐量，但可能更重要的是，領導人選舉算法容許系統恢復足夠快，以防止吞吐量大幅降低，在咱們的觀察中，ZooKeeper用了不到200毫秒的時間就選出了一個新的領導者。第三，隨着追隨者的恢復，一旦開始處理請求，ZooKeeper就可以再次提升吞吐量。

ZooKeeper項目

ZooKeeper已經成功地應用於許多工業領域，它在Yahoo!中用做Yahoo! Message Broker的協調和故障恢復服務，那是一個高度可伸縮的發佈-訂閱系統，用於管理數千個主題的複製和數據傳遞，它被Yahoo! crawler的抓取服務所使用，該服務還管理故障恢復，許多Yahoo!廣告系統也使用ZooKeeper來實現可靠的服務。

鼓勵全部用戶和開發人員加入社區並貢獻他們的專業知識，有關更多信息，請參閱Apache上的Zookeeper項目。