前言

ZooKeeper 是一個開源的分散式協調服務，由雅虎建立，是 Google Chubby 的開源實現。分散式應用程式可以基於 ZooKeeper 實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。

1、簡介

ZooKeeper 是一個開源的分散式協調服務，由雅虎建立，是 Google Chubby 的開源實現。分散式應用程式可以基於 ZooKeeper 實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。

2、基本概念

本節將介紹 ZooKeeper 的幾個核心概念。這些概念貫穿於之後對 ZooKeeper 更深入的講解，因此有必要預先了解這些概念。

2.1 叢集角色

在 ZooKeeper 中，有三種角色：

• Leader

• Follower

• Observer

一個 ZooKeeper 叢集同一時刻只會有一個 Leader，其他都是 Follower 或 Observer。

ZooKeeper 配置很簡單，每個節點的配置檔案(zoo.cfg)都是一樣的，只有 myid 檔案不一樣。myid 的值必須是 zoo.cfg中server.{數值} 的{數值}部分。

zoo.cfg 檔案內容示例：

ZooKeeper

在裝有 ZooKeeper 的機器的終端執行 zookeeper-server status 可以看當前節點的 ZooKeeper 是什麼角色（Leader or Follower）。

ZooKeeper

如上，node-20-104 是 Leader，node-20-103 是 follower。

ZooKeeper 預設只有 Leader 和 Follower 兩種角色，沒有 Observer 角色。為了使用 Observer 模式，在任何想變成Observer的節點的配置檔案中加入:peerType=observer 並在所有 server 的配置檔案中，配置成 observer 模式的 server 的那行配置追加 :observer，例如：

server.1:localhost:2888:3888:observer

ZooKeeper 叢集的所有機器通過一個 Leader 選舉過程來選定一臺被稱為『Leader』的機器，Leader伺服器為客戶端提供讀和寫服務。

Follower 和 Observer 都能提供讀服務，不能提供寫服務。兩者唯一的區別在於，Observer 機器不參與 Leader 選舉過程，也不參與寫操作的『過半寫成功』策略，因此 Observer 可以在不影響寫效能的情況下提升叢集的讀效能。

2.2 會話（Session）

Session 是指客戶端會話，在講解客戶端會話之前，我們先來了解下客戶端連線。在 ZooKeeper 中，一個客戶端連線是指客戶端和 ZooKeeper 伺服器之間的TCP長連線。

ZooKeeper 對外的服務埠預設是2181，客戶端啟動時，首先會與伺服器建立一個TCP連線，從第一次連線建立開始，客戶端會話的生命週期也開始了，通過這個連線，客戶端能夠通過心跳檢測和伺服器保持有效的會話，也能夠向 ZooKeeper 伺服器傳送請求並接受響應，同時還能通過該連線接收來自伺服器的 Watch 事件通知。

Session 的 SessionTimeout 值用來設定一個客戶端會話的超時時間。當由於伺服器壓力太大、網路故障或是客戶端主動斷開連線等各種原因導致客戶端連線斷開時，只要在 SessionTimeout 規定的時間內能夠重新連線上叢集中任意一臺伺服器，那麼之前建立的會話仍然有效。

2.3 資料節點（ZNode）

在談到分散式的時候，一般『節點』指的是組成叢集的每一臺機器。而ZooKeeper 中的資料節點是指資料模型中的資料單元，稱為 ZNode。ZooKeeper 將所有資料儲存在記憶體中，資料模型是一棵樹（ZNode Tree），由斜槓（/）進行分割的路徑，就是一個ZNode，如 /hbase/master，其中 hbase 和 master 都是 ZNode。每個 ZNode 上都會儲存自己的資料內容，同時會儲存一系列屬性資訊。

注：

這裡的 ZNode 可以理解成既是Unix裡的檔案，又是Unix裡的目錄。因為每個 ZNode 不僅本身可以寫資料（相當於Unix裡的檔案），還可以有下一級檔案或目錄（相當於Unix裡的目錄）。

在 ZooKeeper 中，ZNode 可以分為持久節點和臨時節點兩類。

• 持久節點

所謂持久節點是指一旦這個 ZNode 被建立了，除非主動進行 ZNode 的移除操作，否則這個 ZNode 將一直儲存在 ZooKeeper 上。

• 臨時節點

臨時節點的生命週期跟客戶端會話繫結，一旦客戶端會話失效，那麼這個客戶端建立的所有臨時節點都會被移除。

另外，ZooKeeper 還允許使用者為每個節點新增一個特殊的屬性：SEQUENTIAL。一旦節點被標記上這個屬性，那麼在這個節點被建立的時候，ZooKeeper 就會自動在其節點後面追加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。

2.4 版本

ZooKeeper 的每個 ZNode 上都會儲存資料，對應於每個 ZNode，ZooKeeper 都會為其維護一個叫作 Stat 的資料結構，Stat 中記錄了這個 ZNode 的三個資料版本，分別是 version（當前ZNode的版本）、cversion（當前ZNode子節點的版本）和 aversion（當前 ZNode 的 ACL 版本）。

2.5 狀態資訊

每個 ZNode 除了儲存資料內容之外，還儲存了 ZNode 本身的一些狀態資訊。用 get 命令可以同時獲得某個 ZNode 的內容和狀態資訊。如下：

ZooKeeper

在 ZooKeeper 中，version 屬性是用來實現樂觀鎖機制中的『寫入校驗』的（保證分散式資料原子性操作）。

2.6 事務操作

在ZooKeeper中，能改變ZooKeeper伺服器狀態的操作稱為事務操作。一般包括資料節點建立與刪除、資料內容更新和客戶端會話建立與失效等操作。對應每一個事務請求，ZooKeeper 都會為其分配一個全域性唯一的事務ID，用 ZXID 表示，通常是一個64位的數字。每一個 ZXID 對應一次更新操作，從這些 ZXID 中可以間接地識別出 ZooKeeper 處理這些事務操作請求的全域性順序。

2.7 Watcher

Watcher（事件監聽器），是 ZooKeeper 中一個很重要的特性。ZooKeeper允許使用者在指定節點上註冊一些 Watcher，並且在一些特定事件觸發的時候，ZooKeeper 服務端會將事件通知到感興趣的客戶端上去。該機制是 ZooKeeper 實現分散式協調服務的重要特性。

2.8 ACL

ZooKeeper 採用 ACL（Access Control Lists）策略來進行許可權控制。ZooKeeper 定義瞭如下5種許可權。

• CREATE: 建立子節點的許可權。

• READ: 獲取節點資料和子節點列表的許可權。

• WRITE：更新節點資料的許可權。

• DELETE: 刪除子節點的許可權。

• ADMIN: 設定節點ACL的許可權。

注意：CREATE 和 DELETE 都是針對子節點的許可權控制。

3. ZooKeeper典型應用場景

ZooKeeper 是一個高可用的分散式資料管理與協調框架。基於對ZAB演算法的實現，該框架能夠很好地保證分散式環境中資料的一致性。也是基於這樣的特性，使得 ZooKeeper 成為了解決分散式一致性問題的利器。

3.1 資料釋出與訂閱（配置中心）

資料釋出與訂閱，即所謂的配置中心，顧名思義就是釋出者將資料釋出到 ZooKeeper 節點上，供訂閱者進行資料訂閱，進而達到動態獲取資料的目的，實現配置資訊的集中式管理和動態更新。

在我們平常的應用系統開發中，經常會碰到這樣的需求：系統中需要使用一些通用的配置資訊，例如機器列表資訊、資料庫配置資訊等。這些全域性配置資訊通常具備以下3個特性。

• 資料量通常比較小。

• 資料內容在執行時動態變化。

• 叢集中各機器共享，配置一致。

對於這樣的全域性配置資訊就可以釋出到 ZooKeeper上，讓客戶端（叢集的機器）去訂閱該訊息。

釋出/訂閱系統一般有兩種設計模式，分別是推（Push）和拉（Pull）模式。

• 推：服務端主動將資料更新發送給所有訂閱的客戶端。

• 拉：客戶端主動發起請求來獲取最新資料，通常客戶端都採用定時輪詢拉取的方式。

ZooKeeper 採用的是推拉相結合的方式。如下：

客戶端想服務端註冊自己需要關注的節點，一旦該節點的資料發生變更，那麼服務端就會向相應的客戶端傳送Watcher事件通知，客戶端接收到這個訊息通知後，需要主動到服務端獲取最新的資料（推拉結合）。

3.2 命名服務(Naming Service)

命名服務也是分散式系統中比較常見的一類場景。在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務，遠端物件等等——這些我們都可以統稱他們為名字（Name）。

其中較為常見的就是一些分散式服務框架（如RPC、RMI）中的服務地址列表。通過在ZooKeepr裡建立順序節點，能夠很容易建立一個全域性唯一的路徑，這個路徑就可以作為一個名字。

ZooKeeper 的命名服務即生成全域性唯一的ID。

3.3 分散式協調/通知

ZooKeeper 中特有 Watcher 註冊與非同步通知機制，能夠很好的實現分散式環境下不同機器，甚至不同系統之間的通知與協調，從而實現對資料變更的實時處理。使用方法通常是不同的客戶端都對ZK上同一個 ZNode 進行註冊，監聽 ZNode 的變化（包括ZNode本身內容及子節點的），如果 ZNode 發生了變化，那麼所有訂閱的客戶端都能夠接收到相應的Watcher通知，並做出相應的處理。

ZK的分散式協調/通知，是一種通用的分散式系統機器間的通訊方式。

3.3.1 心跳檢測

機器間的心跳檢測機制是指在分散式環境中，不同機器（或程序）之間需要檢測到彼此是否在正常執行，例如A機器需要知道B機器是否正常執行。在傳統的開發中，我們通常是通過主機直接是否可以相互PING通來判斷，更復雜一點的話，則會通過在機器之間建立長連線，通過TCP連線固有的心跳檢測機制來實現上層機器的心跳檢測，這些都是非常常見的心跳檢測方法。

下面來看看如何使用ZK來實現分散式機器（程序）間的心跳檢測。

基於ZK的臨時節點的特性，可以讓不同的程序都在ZK的一個指定節點下建立臨時子節點，不同的程序直接可以根據這個臨時子節點來判斷對應的程序是否存活。通過這種方式，檢測和被檢測系統直接並不需要直接相關聯，而是通過ZK上的某個節點進行關聯，大大減少了系統耦合。

3.3.2 工作進度彙報

在一個常見的任務分發系統中，通常任務被分發到不同的機器上執行後，需要實時地將自己的任務執行進度彙報給分發系統。這個時候就可以通過ZK來實現。在ZK上選擇一個節點，每個任務客戶端都在這個節點下面建立臨時子節點，這樣便可以實現兩個功能：

• 通過判斷臨時節點是否存在來確定任務機器是否存活。

• 各個任務機器會實時地將自己的任務執行進度寫到這個臨時節點上去，以便中心繫統能夠實時地獲取到任務的執行進度。

3.4 Master選舉

Master 選舉可以說是 ZooKeeper 最典型的應用場景了。比如 HDFS 中 Active NameNode 的選舉、YARN 中 Active ResourceManager 的選舉和 HBase 中 Active HMaster 的選舉等。

針對 Master 選舉的需求，通常情況下，我們可以選擇常見的關係型資料庫中的主鍵特性來實現：希望成為 Master 的機器都向資料庫中插入一條相同主鍵ID的記錄，資料庫會幫我們進行主鍵衝突檢查，也就是說，只有一臺機器能插入成功——那麼，我們就認為向資料庫中成功插入資料的客戶端機器成為Master。

依靠關係型資料庫的主鍵特性確實能夠很好地保證在叢集中選舉出唯一的一個Master。

但是，如果當前選舉出的 Master 掛了，那麼該如何處理？誰來告訴我 Master 掛了呢？顯然，關係型資料庫無法通知我們這個事件。但是，ZooKeeper 可以做到！

利用 ZooKeepr 的強一致性，能夠很好地保證在分散式高併發情況下節點的建立一定能夠保證全域性唯一性，即 ZooKeeper 將會保證客戶端無法建立一個已經存在的 ZNode。

也就是說，如果同時有多個客戶端請求建立同一個臨時節點，那麼最終一定只有一個客戶端請求能夠建立成功。利用這個特性，就能很容易地在分散式環境中進行 Master 選舉了。

成功建立該節點的客戶端所在的機器就成為了 Master。同時，其他沒有成功建立該節點的客戶端，都會在該節點上註冊一個子節點變更的 Watcher，用於監控當前 Master 機器是否存活，一旦發現當前的Master掛了，那麼其他客戶端將會重新進行 Master 選舉。

這樣就實現了 Master 的動態選舉。

3.5 分散式鎖

分散式鎖是控制分散式系統之間同步訪問共享資源的一種方式。

分散式鎖又分為排他鎖和共享鎖兩種。

3.5.1 排他鎖

排他鎖（Exclusive Locks，簡稱X鎖），又稱為寫鎖或獨佔鎖。

如果事務T1對資料物件O1加上了排他鎖，那麼在整個加鎖期間，只允許事務T1對O1進行讀取和更新操作，其他任何事務都不能在對這個資料物件進行任何型別的操作（不能再對該物件加鎖），直到T1釋放了排他鎖。

可以看出，排他鎖的核心是如何保證當前只有一個事務獲得鎖，並且鎖被釋放後，所有正在等待獲取鎖的事務都能夠被通知到。

如何利用 ZooKeeper 實現排他鎖？

• 定義鎖

ZooKeeper 上的一個 ZNode 可以表示一個鎖。例如 /exclusive_lock/lock節點就可以被定義為一個鎖。

• 獲得鎖

如上所說，把ZooKeeper上的一個ZNode看作是一個鎖，獲得鎖就通過建立 ZNode 的方式來實現。所有客戶端都去 /exclusive_lock節點下建立臨時子節點 /exclusive_lock/lock。ZooKeeper 會保證在所有客戶端中，最終只有一個客戶端能夠建立成功，那麼就可以認為該客戶端獲得了鎖。同時，所有沒有獲取到鎖的客戶端就需要到/exclusive_lock節點上註冊一個子節點變更的Watcher監聽，以便實時監聽到lock節點的變更情況。

• 釋放鎖

因為 /exclusive_lock/lock 是一個臨時節點，因此在以下兩種情況下，都有可能釋放鎖。

• 當前獲得鎖的客戶端機器發生宕機或重啟，那麼該臨時節點就會被刪除，釋放鎖。

• 正常執行完業務邏輯後，客戶端就會主動將自己建立的臨時節點刪除，釋放鎖。

無論在什麼情況下移除了lock節點，ZooKeeper 都會通知所有在 /exclusive_lock 節點上註冊了節點變更 Watcher 監聽的客戶端。這些客戶端在接收到通知後，再次重新發起分散式鎖獲取，即重複『獲取鎖』過程。

3.5.2 共享鎖

共享鎖（Shared Locks，簡稱S鎖），又稱為讀鎖。如果事務T1對資料物件O1加上了共享鎖，那麼T1只能對O1進行讀操作，其他事務也能同時對O1加共享鎖（不能是排他鎖），直到O1上的所有共享鎖都釋放後O1才能被加排他鎖。

總結：可以多個事務同時獲得一個物件的共享鎖（同時讀），有共享鎖就不能再加排他鎖（因為排他鎖是寫鎖）

4、ZooKeeper在大型分散式系統中的應用

前面已經介紹了 ZooKeeper 的典型應用場景。本節將以常見的大資料產品 Hadoop 和 HBase 為例來介紹 ZooKeeper 在其中的應用，幫助大家更好地理解 ZooKeeper 的分散式應用場景。

4.1 ZooKeeper在Hadoop中的應用

在 Hadoop 中，ZooKeeper 主要用於實現 HA(Hive Availability），包括 HDFS的 NamaNode 和 YARN 的 ResourceManager 的 HA。同時，在 YARN 中， ZooKeepr 還用來儲存應用的執行狀態。

HDFS 的 NamaNode 和 YARN 的 ResourceManager 利用 ZooKeepr 實現 HA 的原理是一樣的，所以本節以YARN為例來介紹。

ZooKeeper

從上圖可以看出，YARN主要由ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）和Container四部分組成。其中最核心的就是ResourceManager。

ResourceManager 負責叢集中所有資源的統一管理和分配，同時接收來自各個節點（NodeManager）的資源彙報資訊，並把這些資訊按照一定的策略分配給各個應用程式（Application Manager），其內部維護了各個應用程式的ApplicationMaster資訊、NodeManager資訊以及資源使用資訊等。

為了實現HA，必須有多個ResourceManager並存（一般就兩個），並且只有一個ResourceManager處於Active狀態，其他的則處於Standby狀態，當Active節點無法正常工作（如機器宕機或重啟）時，處於Standby的就會通過競爭選舉產生新的Active節點。

4.2 主備切換

下面我們就來看看YARN是如何實現多個ResourceManager之間的主備切換的。

1. 建立鎖節點

在 ZooKeeper 上會有一個/yarn-leader-election/appcluster-yarn的鎖節點，所有的 ResourceManager 在啟動的時候，都會去競爭寫一個Lock子節點：/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb，該節點是臨時節點。

ZooKeepr 能夠為我們保證最終只有一個ResourceManager能夠建立成功。建立成功的那個 ResourceManager 就切換為 Active 狀態，沒有成功的那些 ResourceManager 則切換為 Standby 狀態。

ZooKeeper

可以看到此時叢集中 ResourceManager2 為 Active。

1. 註冊 Watcher 監聽

   所有 Standby 狀態的 ResourceManager 都會向 /yarn-leader-election/appcluster-yarn/ActiveBreadCrumb 節點註冊一個節點變更的Watcher監聽，利用臨時節點的特性，能夠快速感知到Active狀態的ResourceManager的執行情況。

2. 主備切換

   當Active狀態的ResourceManager出現諸如宕機或重啟的異常情況時，其在ZooKeeper上連線的客戶端會話就會失效，因此/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb節點就會被刪除。此時其餘各個Standby狀態的ResourceManager就都會接收到來自ZooKeeper服務端的Watcher事件通知，然後會重複進行步驟1的操作。

以上就是利用 ZooKeeper 來實現 ResourceManager 的主備切換的過程，實現了 ResourceManager 的HA。

HDFS 中 NameNode 的 HA 的實現原理跟 YARN 中 ResourceManager 的 HA 的實現原理相同。其鎖節點為 /hadoop-ha/mycluster/ActiveBreadCrumb。

4.3 ResourceManager狀態儲存

在 ResourceManager 中，RMStateStore 能夠儲存一些 RM 的內部狀態資訊，包括 Application 以及它們的 Attempts 資訊、Delegation Token 及 Version Information 等。需要注意的是，RMStateStore 中的絕大多數狀態資訊都是不需要持久化儲存的，因為很容易從上下文資訊中將其重構出來，如資源的使用情況。在儲存的設計方案中，提供了三種可能的實現，分別如下。

• 基於記憶體實現，一般是用於日常開發測試。

• 基於檔案系統的實現，如HDFS。

• 基於 ZooKeeper 實現。

由於這些狀態資訊的資料量都不是很大，因此 Hadoop 官方建議基於 ZooKeeper 來實現狀態資訊的儲存。在 ZooKeepr 上，ResourceManager 的狀態資訊都被儲存在 /rmstore 這個根節點下面。

ZooKeeper

RMAppRoot 節點下儲存的是與各個 Application 相關的資訊，RMDTSecretManagerRoot 儲存的是與安全相關的 Token 等資訊。每個 Active 狀態的 ResourceManager 在初始化階段都會從 ZooKeeper 上讀取到這些狀態資訊，並根據這些狀態資訊繼續進行相應的處理。

4.4 小結：

ZooKeepr 在 Hadoop 中的應用主要有：

1. HDFS 中 NameNode 的 HA 和 YARN 中 ResourceManager 的 HA。

2. 儲存 RMStateStore 狀態資訊

5、ZooKeeper在HBase中的應用

HBase 主要用 ZooKeeper 來實現 HMaster 選舉與主備切換、系統容錯、RootRegion 管理、Region狀態管理和分散式 SplitWAL 任務管理等。

5.1 HMaster選舉與主備切換

HMaster選舉與主備切換的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。

5.2 系統容錯

當 HBase 啟動時，每個 RegionServer 都會到 ZooKeeper 的/hbase/rs節點下建立一個資訊節點（下文中，我們稱該節點為”rs狀態節點”），例如/hbase/rs/[Hostname]，同時，HMaster 會對這個節點註冊監聽。當某個 RegionServer 掛掉的時候，ZooKeeper 會因為在一段時間內無法接受其心跳（即 Session 失效），而刪除掉該 RegionServer 伺服器對應的 rs 狀態節點。

與此同時，HMaster 則會接收到 ZooKeeper 的 NodeDelete 通知，從而感知到某個節點斷開，並立即開始容錯工作。

HBase 為什麼不直接讓 HMaster 來負責 RegionServer 的監控呢？如果 HMaster 直接通過心跳機制等來管理RegionServer的狀態，隨著叢集越來越大，HMaster 的管理負擔會越來越重，另外它自身也有掛掉的可能，因此資料還需要持久化。在這種情況下，ZooKeeper 就成了理想的選擇。

5.3 RootRegion管理

對應 HBase 叢集來說，資料儲存的位置資訊是記錄在元資料 region，也就是 RootRegion 上的。每次客戶端發起新的請求，需要知道資料的位置，就會去查詢 RootRegion，而 RootRegion 自身位置則是記錄在 ZooKeeper 上的（預設情況下，是記錄在 ZooKeeper 的/hbase/meta-region-server節點中）。

當 RootRegion 發生變化，比如 Region 的手工移動、重新負載均衡或 RootRegion 所在伺服器發生了故障等是，就能夠通過 ZooKeeper 來感知到這一變化並做出一系列相應的容災措施，從而保證客戶端總是能夠拿到正確的 RootRegion 資訊。

5.4 Region管理

HBase 裡的 Region 會經常發生變更，這些變更的原因來自於系統故障、負載均衡、配置修改、Region 分裂與合併等。一旦 Region 發生移動，它就會經歷下線（offline）和重新上線（online）的過程。

在下線期間資料是不能被訪問的，並且 Region 的這個狀態變化必須讓全域性知曉，否則可能會出現事務性的異常。

對於大的 HBase 叢集來說，Region 的數量可能會多達十萬級別，甚至更多，這樣規模的 Region 狀態管理交給 ZooKeeper 來做也是一個很好的選擇。

相關推薦