一、Zookeeper簡介

Zookeeper是一個開源的分散式協調服務，目前由Apache進行維護。Zookeeper可以用於實現分散式系統中常見的釋出/訂閱、負載均衡、命令服務、分散式協調/通知、叢集管理、Master選舉、分散式鎖和分散式佇列等功能。它具有以下特性：

• 順序一致性：從一個客戶端發起的事務請求，最終都會嚴格按照其發起順序被應用到Zookeeper中；
• 原子性：所有事務請求的處理結果在整個叢集中所有機器上都是一致的；不存在部分機器應用了該事務，而另一部分沒有應用的情況；
• 單一檢視：所有客戶端看到的服務端資料模型都是一致的；
• 可靠性：一旦服務端成功應用了一個事務，則其引起的改變會一直保留，直到被另外一個事務所更改；
• 實時性：一旦一個事務被成功應用後，Zookeeper可以保證客戶端立即可以讀取到這個事務變更後的最新狀態的資料。

二、Zookeeper設計目標

Zookeeper致力於為那些高吞吐的大型分散式系統提供一個高效能、高可用、且具有嚴格順序訪問控制能力的分散式協調服務。它具有以下四個目標：

2.1 目標一：簡單的資料模型

Zookeeper通過樹形結構來儲存資料，它由一系列被稱為ZNode的資料節點組成，類似於常見的檔案系統。不過和常見的檔案系統不同，Zookeeper將資料全量儲存在記憶體中，以此來實現高吞吐，減少訪問延遲。

2.2 目標二：構建叢集

可以由一組Zookeeper服務構成Zookeeper叢集，叢集中每臺機器都會單獨在記憶體中維護自身的狀態，並且每臺機器之間都保持著通訊，只要叢集中有半數機器能夠正常工作，那麼整個叢集就可以正常提供服務。

2.3 目標三：順序訪問

對於來自客戶端的每個更新請求，Zookeeper都會分配一個全域性唯一的遞增ID，這個ID反映了所有事務請求的先後順序。

2.4 目標四：高效能高可用

ZooKeeper將資料存全量儲在記憶體中以保持高效能，並通過服務叢集來實現高可用，由於Zookeeper的所有更新和刪除都是基於事務的，所以其在讀多寫少的應用場景中有著很高的效能表現。

三、核心概念

3.1 叢集角色

Zookeeper叢集中的機器分為以下三種角色：

• Leader ：為客戶端提供讀寫服務，並維護叢集狀態，它是由叢集選舉所產生的；
• Follower ：為客戶端提供讀寫服務，並定期向Leader彙報自己的節點狀態。同時也參與寫操作“過半寫成功”的策略和Leader的選舉；
• Observer ：為客戶端提供讀寫服務，並定期向Leader彙報自己的節點狀態，但不參與寫操作“過半寫成功”的策略和Leader的選舉，因此Observer可以在不影響寫效能的情況下提升叢集的讀效能。

3.2 會話

Zookeeper客戶端通過TCP長連線連線到服務叢集，會話(Session)從第一次連線開始就已經建立，之後通過心跳檢測機制來保持有效的會話狀態。通過這個連線，客戶端可以傳送請求並接收響應，同時也可以接收到Watch事件的通知。

關於會話中另外一個核心的概念是sessionTimeOut(會話超時時間)，當由於網路故障或者客戶端主動斷開等原因，導致連線斷開，此時只要在會話超時時間之內重新建立連線，則之前建立的會話依然有效。

3.3 資料節點

Zookeeper資料模型是由一系列基本資料單元Znode(資料節點)組成的節點樹，其中根節點為/。每個節點上都會儲存自己的資料和節點資訊。Zookeeper中節點可以分為兩大類：

• 持久節點 ：節點一旦建立，除非被主動刪除，否則一直存在；
• 臨時節點 ：一旦建立該節點的客戶端會話失效，則所有該客戶端建立的臨時節點都會被刪除。

臨時節點和持久節點都可以新增一個特殊的屬性：SEQUENTIAL，代表該節點是否具有遞增屬性。如果指定該屬性，那麼在這個節點建立時，Zookeeper會自動在其節點名稱後面追加一個由父節點維護的遞增數字。

3.4 節點資訊

每個ZNode節點在儲存資料的同時，都會維護一個叫做Stat的資料結構，裡面儲存了關於該節點的全部狀態資訊。如下：

3.5 Watcher

Zookeeper中一個常用的功能是Watcher(事件監聽器)，它允許使用者在指定節點上針對感興趣的事件註冊監聽，當事件發生時，監聽器會被觸發，並將事件資訊推送到客戶端。該機制是Zookeeper實現分散式協調服務的重要特性。

3.6 ACL

Zookeeper採用ACL(Access Control Lists)策略來進行許可權控制，類似於UNIX檔案系統的許可權控制。它定義瞭如下五種許可權：

• CREATE：允許建立子節點；
• READ：允許從節點獲取資料並列出其子節點；
• WRITE：允許為節點設定資料；
• DELETE：允許刪除子節點；
• ADMIN：允許為節點設定許可權。

四、ZAB協議

4.1 ZAB協議與資料一致性

ZAB協議是Zookeeper專門設計的一種支援崩潰恢復的原子廣播協議。通過該協議，Zookeepe基於主從模式的系統架構來保持叢集中各個副本之間資料的一致性。具體如下：

Zookeeper使用一個單一的主程序來接收並處理客戶端的所有事務請求，並採用原子廣播協議將資料狀態的變更以事務Proposal的形式廣播到所有的副本程序上去。如下圖：

具體流程如下：

所有的事務請求必須由唯一的Leader服務來處理，Leader服務將事務請求轉換為事務Proposal，並將該Proposal分發給叢集中所有的Follower服務。如果有半數的Follower服務進行了正確的反饋，那麼Leader就會再次向所有的Follower發出Commit訊息，要求將前一個Proposal進行提交。

4.2 ZAB協議的內容

ZAB協議包括兩種基本的模式，分別是崩潰恢復和訊息廣播：

1. 崩潰恢復

當整個服務框架在啟動過程中，或者當Leader伺服器出現異常時，ZAB協議就會進入恢復模式，通過過半選舉機制產生新的Leader，之後其他機器將從新的Leader上同步狀態，當有過半機器完成狀態同步後，就退出恢復模式，進入訊息廣播模式。

2. 訊息廣播

ZAB協議的訊息廣播過程使用的是原子廣播協議。在整個訊息的廣播過程中，Leader伺服器會每個事物請求生成對應的Proposal，併為其分配一個全域性唯一的遞增的事務ID(ZXID)，之後再對其進行廣播。具體過程如下：

Leader服務會為每一個Follower伺服器分配一個單獨的佇列，然後將事務Proposal依次放入佇列中，並根據FIFO(先進先出)的策略進行訊息傳送。Follower服務在接收到Proposal後，會將其以事務日誌的形式寫入本地磁碟中，並在寫入成功後反饋給Leader一個Ack響應。當Leader接收到超過半數Follower的Ack響應後，就會廣播一個Commit訊息給所有的Follower以通知其進行事務提交，之後Leader自身也會完成對事務的提交。而每一個Follower則在接收到Commit訊息後，完成事務的提交。

五、Zookeeper的典型應用場景

5.1資料的釋出/訂閱

資料的釋出/訂閱系統，通常也用作配置中心。在分散式系統中，你可能有成千上萬個服務節點，如果想要對所有服務的某項配置進行更改，由於資料節點過多，你不可逐臺進行修改，而應該在設計時採用統一的配置中心。之後釋出者只需要將新的配置傳送到配置中心，所有服務節點即可自動下載並進行更新，從而實現配置的集中管理和動態更新。

Zookeeper通過Watcher機制可以實現資料的釋出和訂閱。分散式系統的所有的服務節點可以對某個ZNode註冊監聽，之後只需要將新的配置寫入該ZNode，所有服務節點都會收到該事件。

5.2 命名服務

在分散式系統中，通常需要一個全域性唯一的名字，如生成全域性唯一的訂單號等，Zookeeper可以通過順序節點的特性來生成全域性唯一ID，從而可以對分散式系統提供命名服務。

5.3 Master選舉

分散式系統一個重要的模式就是主從模式(Master/Salves)，Zookeeper可以用於該模式下的Matser選舉。可以讓所有服務節點去競爭性地建立同一個ZNode，由於Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點能夠建立成功，這樣該服務節點就可以成為Master節點。

5.4 分散式鎖

可以通過Zookeeper的臨時節點和Watcher機制來實現分散式鎖，這裡以排它鎖為例進行說明：

分散式系統的所有服務節點可以競爭性地去建立同一個臨時ZNode，由於Zookeeper不能有路徑相同的ZNode，必然只有一個服務節點能夠建立成功，此時可以認為該節點獲得了鎖。其他沒有獲得鎖的服務節點通過在該ZNode上註冊監聽，從而當鎖釋放時再去競爭獲得鎖。鎖的釋放情況有以下兩種：

• 當正常執行完業務邏輯後，客戶端主動將臨時ZNode刪除，此時鎖被釋放；
• 當獲得鎖的客戶端發生宕機時，臨時ZNode會被自動刪除，此時認為鎖已經釋放。

當鎖被釋放後，其他服務節點則再次去競爭性地進行建立，但每次都只有一個服務節點能夠獲取到鎖，這就是排他鎖。

5.5 叢集管理

Zookeeper還能解決大多數分散式系統中的問題：

• 如可以通過建立臨時節點來建立心跳檢測機制。如果分散式系統的某個服務節點宕機了，則其持有的會話會超時，此時該臨時節點會被刪除，相應的監聽事件就會被觸發。
• 分散式系統的每個服務節點還可以將自己的節點狀態寫入臨時節點，從而完成狀態報告或節點工作進度彙報。
• 通過資料的訂閱和釋出功能，Zookeeper還能對分散式系統進行模組的解耦和任務的排程。
• 通過監聽機制，還能對分散式系統的服務節點進行動態上下線，從而實現服務的動態擴容。

參考資料

1. 倪超 . 從Paxos到Zookeeper——分散式一致性原理與實踐 . 電子工業出版社 . 2015-02-01

更多大資料系列文章可以參見個人 GitHub 開源專案： 大資料入門指南