ZooKeeper 基礎入門

什麼是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. 失敗和恢復不一樣的 follower
3. 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分佈式一致性原理與實踐》