zookeeper學習筆記

zookeeper學習筆記

前言

ZooKeeper是一種用於分佈式應用程序的分佈式開源協調服務。它提供了一些簡單的源函數，分佈式應用程序能夠調用這些源函數，以實現更高級別的服務，能夠實現同步、配置文件維護以及分組和命名。它被設計爲易於編程，並使用相似文件系統目錄樹結構的數據模型。它使用java實現，裏面也能夠調用C語言。

設計目標

1. zookeeper是簡單的
   ZooKeeper容許分佈式進程經過共享的層級命名空間相互協調，該命名空間的結構與標準文件系統相似。名稱空間由數據寄存器組成--在ZooKeeper中稱爲znodes，這些與文件和目錄相似。與專爲存儲而設計的典型文件系統不一樣，ZooKeeper數據保存在內存中，將支持ZooKeeper能夠實現高吞吐量和低延遲。
2. zookeeper是可複製的
   與它協調的分佈式進程同樣，ZooKeeper自己也能夠在稱爲集合的一組主機上進行復制。組成ZooKeeper服務的ZK服務之間必須彼此瞭解。它們維護內存中的狀態圖像，以及持久性存儲(硬盤存儲)中的事務日誌和快照。只要大多數ZK服務可用，ZooKeeper服務就可用。客戶端鏈接到單個ZK服務，客戶端維護TCP鏈接，經過該鏈接發送請求，獲取響應，獲取監視事件以及發送心跳。若是與ZK服務的TCP鏈接中斷，則客戶端將鏈接到其餘ZK服務。
   
3. zookeeper是可排序的
   ZooKeeper使用反映全部ZooKeeper事務順序的數字標記每一個更新。後續操做可使用該特性來實現更高級別的抽象，例如同步源函數。
4. zookeeper是迅速的
   它在以讀取數據爲主的系統中，是很是快的。ZooKeeper應用程序在數千臺計算機上運行，而且在讀取比寫入更常見的狀況下表現最佳，比例大約爲10：1。
5. 數據模型和分層命名空間
   ZooKeeper提供的名稱空間很是相似於標準文件系統。名稱是由斜槓"/"分隔的路徑組成,ZooKeeper名稱空間中的每一個節點都由路徑標識。

ZooKeeper's Hierarchical Namespace

1. 節點和臨時節點
   ZooKeeper中使用術語znode表示數據節點。與標準文件系統不一樣，ZooKeeper命名空間中的每一個節點均可以包含與之關聯的數據以及子項。就像一個容許文件也是目錄的文件系統。(zookeeper的設計是用來保存協調數據，好比狀態信息、配置信息、本地信息等，一般存儲在一個節點上的數據都比較小，處於byte到kb之間。)

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

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

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

2. 有條件的更新和監聽。
   Zookeeper支持監聽。Client能夠設置監聽指定的znode。當znode更改時，將觸發並刪除watch。當觸發watch時，Client會收到一個數據包，說明znode已更改。若是Client與其中一個ZK服務之間的鏈接中斷，Client將收到本地通知，這些能夠用於[tbd]。

3. 擔保
   ZooKeeper很是快速並且很是簡單。可是，因爲其目標是構建更復雜的服務（如同步）的基礎，所以它提供了一系列保證。這些是：

   • 順序一致性 - 客戶端的更新將按發送順序應用。
   • 原子性 - 更新成功或失敗。沒有其餘結果。
   • 單系統映像 - 不管服務器鏈接到哪一個服務器，客戶端都將看到相同的服務視圖。
   • 可靠性 - 一旦數據更新成功，它將保證客戶端也覆蓋更新。
   • 及時性 - 系統的客戶視圖保證在特定時間範圍內是最新的。

4. 簡單的API
   ZooKeeper的設計目標之一是提供一個很是簡單的編程接口。所以，它僅支持如下操做：

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

5. 實現原理
   下圖顯示ZooKeeper的高級組件。
   ZooKeeper Components
   

   複製數據庫是包含整個數據樹的內存數據庫。將更新記錄到磁盤以得到可恢復性，而且寫入的數據在應用於內存數據庫以前會序列化到磁盤。

   每一個ZooKeeper服務器都爲客戶端服務。客戶端只鏈接到一臺服務器提交請求，讀取請求由每一個服務器數據庫的本地副本提供服務。更改狀態的服務請求，寫請求，由agreement協議處理。

   做爲agreement協議的一部分，來自客戶端的全部寫入請求都被轉發到Leader服務器。其他的ZooKeeper服務器（fllowers）接收來自Leader的消息提議並贊成消息傳遞。消息傳遞層負責Leader更新失敗時，同步Fllowers和Leader。

   ZooKeeper使用自定義原子消息傳遞協議。因爲消息傳遞層是原子的，所以ZooKeeper能夠保證本地副本永遠不會出現誤差。當領導者收到寫入請求時，它會查看寫入並被應用到內存數據庫時的系統狀態，並在一個事務中更改狀態爲新狀態。

6. 性能表現
   

   圖中數據爲910個Client去發請求，橫軸爲讀請求在全部請求中的佔比，縱軸爲服務吞吐量。讀請求和寫請求的數據量都是1KB。servers表示ZK集羣大小，即ZooKeeper的服務器數量。大約30個Client，其中ZooKeeper的Lwader節點不容許Client鏈接。
   在讀取數量超過寫入的應用程序中，它的性能尤爲高，由於寫入涉及同步全部服務器的狀態。

7. 可靠性
   爲了在注入故障時顯示系統隨時間的行爲，咱們運行了由7臺機器組成的ZooKeeper集羣服務。咱們運行與之前相同的飽和度基準，但此次咱們將寫入百分比保持在恆定的30％，這是咱們預期工做量的保守比率。
   

在請求失敗時，可以成功的響應，圖中標記的錯誤事件以下：
①fllower的宕機和恢復
②另外一個fllower的宕機和恢復
③一個leader的宕機
④兩個fllower的宕機和恢復
⑤另外一個leader的宕機

觀察圖中的數據能夠獲得，首先看fllower宕機並迅速恢復，即便fllower宕機，ZooKeeper也可以維持高吞吐量。也許更重要的是，leader選舉算法容許系統足夠快地恢復以防止吞吐量大幅降低。咱們能夠看到，ZooKeeper選擇新leader的時間不到200毫秒。隨着fllower的恢復，ZooKeeper可以在新fllower開始處理請求後再次提升吞吐量。

轉載請註明出處：https://www.cnblogs.com/zooqkl