關注上方藍字關注我們
什麼是ZooKeeper
Apache ZooKeeper 是一個開源的實現高可用的分佈式協調服務器。ZooKeeper是一種集中式服務，用於維護配置信息，域名服務，提供分佈式同步和集羣管理。所有這些服務的種類都被應用在分佈式環境中，每一次實施這些都會做很多工作來避免出現bug和競爭條件。
ZooKeeper 設計原則
ZooKeeper 很簡單
ZooKeeper 允許分佈式進程通過共享的分層命名空間相互協調，ZooKeeper命名空間與文件系統很相似，每個命名空間填充了數據節點的註冊信息 - 叫做Znode，這是在 ZooKeeper 中的叫法，Znode 很像我們文件系統中的文件和目錄。ZooKeeper 與典型的文件系統不同，ZooKeeper 數據保存在內存中，這意味着 ZooKeeper 可以實現高吞吐量和低時延。
ZooKeeper 可複製
與它協調的分佈式進程一樣，ZooKeeper本身也可以在稱爲集羣的一組主機上進行復制。
組成 ZooKeeper 服務的單個服務端必須瞭解彼此。它們維護內存中的狀態、持久性的事務日誌和快照。只要大多數服務可用，ZooKeeper 服務就可用。
客戶端可以連接到單個的服務器。客戶端通過連接單個服務器進而維護 TCP 連接，通過連接發送請求，獲取響應，獲取監聽事件以及發送心跳，很像Eureka Server 的功能。如果與單個服務器的連接中斷，客戶端會自動的連接到ZooKeeper Service 中的其他服務器。
ZooKeeper 有序
ZooKeeper使用時間戳來記錄導致狀態變更的事務性操作，也就是說，一組事務通過時間戳來保證有序性。基於這一特性。ZooKeeper可以實現更加高級的抽象操作，如同步等。
ZooKeeper 非常快
ZooKeeper包括讀寫兩種操作，基於ZooKeeper的分佈式應用，如果是讀多寫少的應用場景（讀寫比例大約是10:1），那麼讀性能更能夠體現出高效。
ZooKeeper基本概念
數據模型和分層命名空間
ZooKeeper提供的命名空間非常類似於標準文件系統。名稱是由斜槓（/）分隔的路徑元素序列。ZooKeeper名稱空間中的每個節點都由路徑標識。
ZooKeeper的分層命名空間圖
節點和臨時節點
與標準的文件系統所不同的是，ZooKeeper命名空間中的每個節點都可以包含與之關聯的數據以及子項，這就像一個文件也是目錄的文件系統。ZooKeeper被設計用來存儲分佈式數據：狀態信息，配置，定位信息等等。所以每個ZooKeeper 節點能存儲的容量非常小，最大容量爲 1MB。我們使用術語 Znode 來表明我們正在談論ZooKeeper數據節點。
Znodes 維護了一個 stat 結構，包括數據變更，ACL更改和時間戳的版本號，用來驗證緩存和同步更新。每一次Znode 的數據發生了變化，版本號的數量就會進行增加。每當客戶端檢索某個znode 數據時，它也會接收該數據的版本。
命名空間下數據存儲的Znode 節點都會以原子性的方式讀寫，也就是保證了原子性。讀取所有Znode 相關聯的節點數據並通過寫的方式替換節點數據。每一個節點都會有一個 訪問控制列表（ACL）的限制來判斷誰可以進行操作。
ZooKeeper 也有臨時節點的概念。只要創建的 Znode 的會話(session)處於活動狀態，就會存在這些臨時節點。當會話結束，臨時節點也就被刪除。
選擇性更新和watches
ZooKeeper支持watches的概念。客戶端可以在 Znode 上設置監聽。當 Znode 發生變化時，監聽會被觸發並移除。觸發監聽時，客戶端會收到一個數據包告知 Znode 發生變更。如果客戶端與其中一個 ZooKeeper 服務器之間的連接中斷，則客戶端將收到本地通知。
集羣角色
通常在分佈式系統中，構成一個集羣中的每一臺機器都有一個自己的角色，最典型的集羣模式就是 master/slave (主備模式)。在這種模式中，我們把能夠處理寫操作請求的機器成爲 Master ，把所有通過異步複製方式獲取最新數據，並提供讀請求服務的機器成爲 Slave 機器。
而 ZooKeeper 沒有采用這種方式，ZooKeeper 引用了 Leader、Follower和 Observer 三個角色。ZooKeeper 集羣中的所有機器通過選舉的方式選出一個 Leader，Leader 可以爲客戶端提供讀服務和寫服務。除了 Leader 外，集羣中還包括了 Follower 和 Observer 。Follower 和 Observer 都能夠提供讀服務，唯一區別在於，*Observer * 不參與 Leader 的選舉過程，也不寫操作的"過半寫成功"策略，因此 Observer 可以在不影響寫性能的情況下提升集羣的讀性能。
Session
Session 指的是客戶端會話，在講解會話之前先來了解一下客戶端連接。客戶端連接指的就是客戶端和服務器之間的一個 TCP長連接，ZooKeeper 對外的端口是 2181，客戶端啓動的時候會與服務器建立一個 TCP 連接，從第一次連接建立開始，客戶端會話的生命週期也就開始了，通過這個連接，客戶端能夠通過心跳檢測與服務器保證有效的會話，也能夠向 ZooKeeper 服務器發送請求並接受響應，同時還能夠通過該連接來接收來自服務器的Watch 事件通知。
ZooKeeper 特性
一致性要求
ZooKeeper 非常快並且很簡單。但是，由於其開發的目的在於構建更復雜的服務(如同步)的基礎，因此它提供了一系列的保證，這些保證是：
•順序一致性：客戶端的更新將按順序應用。•原子性：更新要麼成功要麼失敗，沒有其他結果•單一視圖：無論客戶端連接到哪個服務，所看到的環境都是一樣的•可靠性：開始更新後，它將從該時間開始，一直到客戶端覆蓋更新•及時性：系統的客戶視圖保證在特定時間範圍內是最新的。
簡單的API使用
ZooKeeper 設計之初提供了非常簡單的編程接口。作爲結果，它支持以下操作：
•create：在文檔目錄樹中的某一個位置創建節點•delete: 刪除節點•exists: 測試某個位置是否存在節點•get data: 從節點中讀取數據•set data: 向節點中寫數據•get children: 從節點中檢索子節點列表•sync: 等待數據傳播
實現
ZooKeeper Components 展現了ZooKeeper 服務的高級組件。除請求處理器外，構成 ZooKeeper 服務的每個服務器都複製其自己的每個組件的副本。
圖中的 Replicated Database (可複製的數據庫)是一個包含了整個數據樹的內存數據庫。更新將記錄到磁盤以獲得可恢復性，並且寫入在應用到內存數據庫之前會得到序列化。
每一個 ZooKeeper 服務器都爲客戶端服務。客戶端只連接到一臺服務器用以提交請求。讀請求由每個服務器數據庫的本地副本提供服務，請求能夠改變服務的狀態，寫請求由"同意協議"進行通過。
作爲"同意協議" 的一部分，所有的請求都遵從一個單個的服務，由這個服務來詢問除自己之外其他服務是否可以同意寫請求，而這個單個的服務被稱爲Leader。除自己之外其他的服務被稱爲follower，它們接收來自Leader 的消息並對消息達成一致。消息傳底層負責替換失敗的 leader 並使 follower 與 leader 進行同步。
ZooKeeper 使用自定義的原子性消息傳遞協議。因爲消息傳底層是原子性的，ZooKeeper 能夠保證本地副本永遠不會產生分析或者衝突。當 leader 接收到寫請求時，它會計算系統的狀態以確保寫請求何時應用，並且開啓一個捕獲新狀態的事務。
使用者
ZooKeeper 的編程接口非常簡單，但是通過它，你可以實現更高階的操作。
性能
ZooKeeper 旨在提供高性能，但是真的是這樣嗎？ZooKeeper是由雅虎團隊開發。當讀請求遠遠高於寫請求的時候，它的效率很高，因爲寫操作涉及同步所有服務器的狀態。(讀取數量超過寫入通常是協調服務的情況。)
ZooKeeper吞吐量作爲讀寫比率變化是在具有雙2Ghz Xeon和兩個SATA 15K RPM驅動器的服務器上運行的ZooKeeper版本3.2的吞吐量圖。一個驅動器用作專用的ZooKeeper日誌設備。快照已寫入OS驅動器。寫請求是1K寫入，讀取是1K讀取。“服務器”表示ZooKeeper集合的大小，即構成服務的服務器數量。大約30個其他服務器用於模擬客戶端。ZooKeeper集合的配置使得Leader不允許來自客戶端的連接。(此部分來源於翻譯結果)
基準也表明它也是可靠的。存在錯誤時的可靠性顯示了部署如何響應各種故障。圖中標記的事件如下：
1.follower 的失敗和恢復2.失敗和恢復不同的 follower3.leader 的失敗4.兩個follower 的失敗和恢復5.其他leader 的失敗
可靠性
爲了在注入故障時顯示系統隨時間的行爲，我們運行了由7臺機器組成的ZooKeeper服務。我們運行與以前相同的飽和度基準，但這次我們將寫入百分比保持在恆定的30％，這是我們預期工作量的保守比率。(此部分來源於翻譯結果)
該圖中有一些重要的觀察結果。首先，如果follower 失敗並迅速恢復，那麼即使失敗，ZooKeeper也能夠維持高吞吐量。但也許更重要的是，leader 選舉算法允許系統足夠快地恢復以防止吞吐量大幅下降。在我們的觀察中，ZooKeeper 選擇新 leader 的時間不到200毫秒。第三，隨着follower 的恢復，ZooKeeper能夠在開始處理請求後再次提高吞吐量。
文章來源：
https://zookeeper.apache.org/doc/current/zookeeperOver.html
《從Paxos到zookeeper分佈式一致性原理與實踐》
下面爲自己做個宣傳，歡迎關注公衆號 Java建設者，號主是Java技術棧，熱愛技術，喜歡閱讀，熱衷於分享和總結，希望能把每一篇好文章分享給成長道路上的你。關注公衆號回覆 002 領取爲你特意準備的大禮包，你一定會喜歡並收藏的。
