ZooKeeper 的設計理念和架構

---

---

2 ZooKeeper:因爲協調分佈式系統是一個動物園

ZooKeeper是一種針對分佈式應用程序的高性能協調服務。它在一個簡單的接口中公開了常見的服務——例如命名、配置管理、同步和組服務——因此您不必從頭開始編寫它們。您可以使用它來實現共識、組管理、領導人選舉和到場協議。你可以在此基礎上爲你自己的特定需求而建。

2.1 ZooKeeper Overview:爲客戶端開發人員、管理員和貢獻者提供的技術概述文檔。

2.1.1 Overview：ZooKeeper 的鳥瞰圖，包括設計理念和建築。

ZooKeeper是一個開源的分佈式應用程序協調服務。它公開了一組簡單的原語，分佈式應用程序可以在這些原語的基礎上實現更高級別的服務，用於同步、配置維護、組和命名。它被設計爲易於編程，並使用了一個數據模型，其風格類似於文件系統的目錄樹結構。它運行在Java中，並具有Java和C的綁定。

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

2.1.1.1 設計目標(Design Goals)

ZooKeeper is simple. ZooKeeper允許分佈式進程通過與標準文件系統組織類似的共享層次命名空間相互協調。名稱空間由數據寄存器(用ZooKeeper的話說，稱爲znodes)組成，這些寄存器類似於文件和目錄。與設計用於存儲的典型文件系統不同，ZooKeeper數據保存在內存中，這意味着ZooKeeper可以實現高吞吐量和低延遲數。

ZooKeeper實現非常重視高性能、高可用性和嚴格有序的訪問。ZooKeeper的性能方面意味着它可以用於大型分佈式系統。可靠性方面使其不會成爲單點故障。嚴格的順序意味着可以在客戶機上實現複雜的同步原語。

ZooKeeper is replicated. 和它所協調的分佈式進程一樣，ZooKeeper本身也打算在一組稱爲合集的主機上進行復制。

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

客戶機連接到單個ZooKeeper服務器。客戶機維護一個TCP連接，通過它發送請求、獲取響應、獲取監視事件和發送心跳。如果到服務器的TCP連接中斷，客戶機將連接到另一臺服務器。

ZooKeeper is ordered. ZooKeeper給每個更新貼上一個數字，這個數字反映了所有ZooKeeper事務的順序。後續操作可以使用該順序實現更高級別的抽象，比如同步原語。

ZooKeeper is fast. 在“以讀取爲主”的工作負載中，它尤其快。ZooKeeper應用程序運行在數千臺機器上，當讀操作比寫操作更常見時，它的性能最好，比率約爲10:1。

2.1.1.2 數據模型和層次命名空間(Data model and the hierarchical namespace)

ZooKeeper提供的名稱空間非常類似於標準文件系統。名稱是由斜槓(/)分隔的路徑元素序列。ZooKeeper名稱空間中的每個節點都由一個路徑標識。
ZooKeeper的層次名稱空間:

2.1.1.3 節點和臨時節點(Nodes and ephemeral nodes)

與標準文件系統不同，ZooKeeper名稱空間中的每個節點都可以擁有與其關聯的數據和子節點。這就像一個文件系統允許一個文件同時也是一個目錄。(ZooKeeper的設計目的是存儲協調數據:狀態信息、配置、位置信息等，因此在每個節點上存儲的數據通常很小，以字節到千字節爲單位)。我們使用術語znode來表明我們在討論ZooKeeper數據節點。

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

存儲在名稱空間中的每個znode中的數據是原子式讀寫的。讀取獲取與znode關聯的所有數據字節，而寫入則替換所有數據。每個節點都有一個訪問控制列表(ACL)，用於限制誰可以做什麼。

ZooKeeper也有臨時節點的概念。只要創建znode的會話處於活動狀態，這些znode就會存在。當會話結束時，刪除znode。當您想要實現[tbd]時，臨時節點非常有用。

2.1.1.4 更新條件和觀察(Conditional updates and watches)

ZooKeeper支持手錶的概念。Client可以在znode上設置手錶。當znode發生更改時，將觸發並刪除一個手錶。當一個手錶被觸發時，客戶端收到一個數據包，說znode已經更改。如果客戶機和ZooKeeper服務器之間的連接斷開，客戶機將收到一個本地通知。這些可以用來[tbd]。

2.1.1.5 擔保(Guarantees)

ZooKeeper是非常快，非常簡單。但是，由於它的目標是作爲構建更復雜服務(比如同步)的基礎，所以它提供了一組擔保。這些都是:

• Sequential Consistency - 來自客戶機的更新將按發送順序應用
• Atomicity - 更新成功或失敗。沒有部分結果。
• Single System Image - 無論服務連接到哪個服務器，客戶機都將看到相同的服務視圖。
• Reliability - 一旦應用了更新，它將從那時起一直持續到客戶機覆蓋更新爲止。
• Timeliness - 系統的客戶端視圖保證在一定的時間範圍內是最新的
  有關這些的更多信息，以及如何使用它們，請參見[tbd]

2.1.1.6 Simple API

ZooKeeper的設計目標之一是提供一個非常簡單的編程接口。因此，它只支持以下操作:

• create : 在樹的某個位置創建節點
• delete : 刪除一個節點
• exists : 測試某個位置是否存在節點
• get data : 從節點讀取數據
• set data : 往一個節點裏寫入數據
• get children : 檢索節點的子列表
• sync : 等待要傳播的數據
  如欲更深入地討論這些計劃，以及如何利用這些計劃推行更高層次的運作，請參閱[tbd]

2.1.1.7 實現(Implementation)

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

The replicated database是一個包含整個數據樹的內存數據庫。更新將被記錄到磁盤以獲得可恢復性，寫操作在應用到內存數據庫之前被序列化到磁盤。

每個ZooKeeper服務器都爲客戶端提供服務。客戶機僅連接到一個服務器來提交請求。讀取請求由每個服務器數據庫的本地副本提供服務。更改服務狀態的請求(寫請求)由an agreement protocol處理。

作爲the agreement protocol的一部分，所有來自客戶端的寫請求都被轉發到一個名爲leader的服務器上。其他的ZooKeeper服務器(稱爲追隨者)接收來自領導者的消息建議，並就消息傳遞達成一致。消息層負責在失敗時替換領導者，並將追隨者與領導者同步。

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

2.1.1.8 應用(Uses)

ZooKeeper的編程接口非常簡單。然而，使用它，您可以實現更高階的操作，例如同步原語、組成員關係、所有權等。一些分佈式應用程序使用它來:[tbd: add uses from white paper and video presentation.]詳情請參閱[tbd]

2.1.1.9 性能(Performance)

ZooKeeper被設計成高性能.但真的是這樣嗎?Yahoo!的ZooKeeper開發團隊的研究結果。研究表明確實如此。(See ZooKeeper Throughput as the Read-Write Ratio Varies.)在讀多於寫的應用程序中，它的性能尤其高，因爲寫涉及同步所有服務器的狀態。(讀編號超過寫通常是協調服務的情況。)

ZooKeeper的吞吐量隨着讀寫比的變化而變化，這是一個ZooKeeper 3.2版本的吞吐量曲線圖，運行在兩臺2Ghz Xeon和兩臺SATA 15K RPM驅動器的服務器上。其中一個驅動器用作專用的管理員日誌設備。快照被寫入操作系統驅動器。寫請求爲1K寫，讀請求爲1K讀。“服務器”表示ZooKeeper集合的大小，即組成服務的服務器數量。大約有30臺其他服務器用於模擬客戶機。ZooKeeper集合的配置是這樣的:leaders不允許從客戶端連接。

Note：在3.2 r/w版本中，性能比前一個3.1版本提高了約2倍。
基準測試也表明它是可靠的。錯誤存在時的可靠性顯示了部署如何響應各種故障。圖中標註的事件如下:

• 1.Failure and recovery of a follower
• 2.Failure and recovery of a different follower
• 3.Failure of the leader
• 4.Failure and recovery of two followers
• 5.Failure of another leader

2.1.1.10 可靠性(Reliability)

爲了顯示系統在注入故障時隨時間的行爲，我們運行了一個由7臺機器組成的ZooKeeper服務。我們運行了與以前相同的飽和度基準測試，但這次我們將寫百分比保持在30%不變，這是預期工作負載的保守比例。

從這張圖中有幾個重要的觀察結果。首先，如果跟隨者失敗並迅速恢復，那麼即使失敗了，ZooKeeper仍然能夠維持高吞吐量。但也許更重要的是，leader election算法允許系統恢復得足夠快，以防止吞吐量大幅下降。在我們的觀察中，ZooKeeper用了不到200毫秒的時間選出一個新的領導者。第三，隨着跟隨者的恢復，一旦他們開始處理請求，ZooKeeper就能夠再次提高吞吐量。

2.1.1.11 ZooKeeper項目(The ZooKeeper Project)

ZooKeeper已成功應用於許多工業領域。Yahoo!作爲雅虎的協調和故障恢復服務!Message Broker是一個高度可伸縮的發佈-訂閱系統，管理用於複製和數據交付的數千個主題。它被Yahoo!爬蟲程序，它還管理故障恢復。一些雅虎!廣告系統也使用ZooKeeper來實現可靠的服務。

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