大資料之 ZooKeeper原理及其在Hadoop和HBase中的應用

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

簡介

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

基本概念

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

叢集角色

在ZooKeeper中，有三種角色：

• Leader
• Follower
• Observer

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

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

zoo.cfg檔案內容示例：

maxClientCnxns=0 # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/var/lib/zookeeper/data # the port at which the clients will connect clientPort=2181 # the directory where the transaction logs are stored. dataLogDir=/var/lib/zookeeper/logs server.1=192.168.20.101:2888:3888 server.2=192.168.20.102:2888:3888 server.3=192.168.20.103:2888:3888 server.4=192.168.20.104:2888:3888 server.5=192.168.20.105:2888:3888 minSessionTimeout=4000 maxSessionTimeout=100000

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

[root@node-20-103 ~]# zookeeper-server status JMX enabled by default Using config: /etc/zookeeper/conf/zoo.cfg Mode: follower

[root@node-20-104 ~]# zookeeper-server status JMX enabled by default Using config: /etc/zookeeper/conf/zoo.cfg Mode: leader

如上，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可以在不影響寫效能的情況下提升叢集的讀效能。

會話（Session）

Session是指客戶端會話，在講解客戶端會話之前，我們先來了解下客戶端連線。在ZooKeeper中，一個客戶端連線是指客戶端和ZooKeeper伺服器之間的TCP長連線。ZooKeeper對外的服務埠預設是2181，客戶端啟動時，首先會與伺服器建立一個TCP連線，從第一次連線建立開始，客戶端會話的生命週期也開始了，通過這個連線，客戶端能夠通過心跳檢測和伺服器保持有效的會話，也能夠向ZooKeeper伺服器傳送請求並接受響應，同時還能通過該連線接收來自伺服器的Watch事件通知。Session的SessionTimeout值用來設定一個客戶端會話的超時時間。當由於伺服器壓力太大、網路故障或是客戶端主動斷開連線等各種原因導致客戶端連線斷開時，只要在SessionTimeout規定的時間內能夠重新連線上叢集中任意一臺伺服器，那麼之前建立的會話仍然有效。

資料節點（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就會自動在其節點後面追加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。

版本

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

狀態資訊

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

[zk: localhost:2181(CONNECTED) 23] get /yarn-leader-election/appcluster-yarn/ActiveBreadCrumb   appcluster-yarnrm1 cZxid = 0x1b00133dc0 //Created ZXID,表示該ZNode被建立時的事務ID ctime = Tue Jan 03 15:44:42 CST 2017 //Created Time,表示該ZNode被建立的時間 mZxid = 0x1d00000063 //Modified ZXID，表示該ZNode最後一次被更新時的事務ID mtime = Fri Jan 06 08:44:25 CST 2017 //Modified Time，表示該節點最後一次被更新的時間 pZxid = 0x1b00133dc0 //表示該節點的子節點列表最後一次被修改時的事務ID。注意，只有子節點列表變更了才會變更pZxid，子節點內容變更不會影響pZxid。 cversion = 0 //子節點的版本號 dataVersion = 11 //資料節點的版本號 aclVersion = 0 //ACL版本號 ephemeralOwner = 0x0 //建立該節點的會話的seddionID。如果該節點是持久節點，那麼這個屬性值為0。 dataLength = 22 //資料內容的長度 numChildren = 0 //子節點的個數

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

事務操作

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

Watcher

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

ACL

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

• CREATE: 建立子節點的許可權。
• READ: 獲取節點資料和子節點列表的許可權。
• WRITE：更新節點資料的許可權。
• DELETE: 刪除子節點的許可權。
• ADMIN: 設定節點ACL的許可權。

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

ZooKeeper典型應用場景

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

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

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

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

• 資料量通常比較小。
• 資料內容在執行時動態變化。
• 叢集中各機器共享，配置一致。

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

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

• 推：服務端主動將資料更新傳送給所有訂閱的客戶端。
• 拉：客戶端主動發起請求來獲取最新資料，通常客戶端都採用定時輪詢拉取的方式。

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

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

命名服務(Naming Service)

命名服務也是分散式系統中比較常見的一類場景。在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務，遠端物件等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分散式服務框架（如RPC、RMI）中的服務地址列表。通過在ZooKeepr裡建立順序節點，能夠很容易建立一個全域性唯一的路徑，這個路徑就可以作為一個名字。

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

分散式協調/通知

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

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

心跳檢測

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

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

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

工作進度彙報

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

• 通過判斷臨時節點是否存在來確定任務機器是否存活。
• 各個任務機器會實時地將自己的任務執行進度寫到這個臨時節點上去，以便中心繫統能夠實時地獲取到任務的執行進度。

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的動態選舉。

分散式鎖

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

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

排他鎖

排他鎖（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監聽的客戶端。這些客戶端在接收到通知後，再次重新發起分散式鎖獲取，即重複『獲取鎖』過程。

共享鎖

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

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

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

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

ZooKeeper在Hadoop中的應用

在Hadoop中，ZooKeeper主要用於實現HA(High Availability），包括HDFS的NamaNode和YARN的ResourceManager的HA。同時，在YARN中，ZooKeepr還用來儲存應用的執行狀態。HDFS的NamaNode和YARN的ResourceManager利用ZooKeepr實現HA的原理是一樣的，所以本節以YARN為例來介紹。

YARN架構體系

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

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

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

主備切換

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

1. 建立鎖節點
   在ZooKeeper上會有一個/yarn-leader-election/appcluster-yarn的鎖節點，所有的ResourceManager在啟動的時候，都會去競爭寫一個Lock子節點：/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb，該節點是臨時節點。ZooKeepr能夠為我們保證最終只有一個ResourceManager能夠建立成功。建立成功的那個ResourceManager就切換為Active狀態，沒有成功的那些ResourceManager則切換為Standby狀態。

   [zk: localhost:2181(CONNECTED) 16] get /yarn-leader-election/appcluster-yarn/ActiveBreadCrumb   appcluster-yarnrm2 cZxid = 0x1b00133dc0 ctime = Tue Jan 03 15:44:42 CST 2017 mZxid = 0x1f00000540 mtime = Sat Jan 07 00:50:20 CST 2017 pZxid = 0x1b00133dc0 cversion = 0 dataVersion = 28 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 22 numChildren = 0

可以看到此時叢集中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。

ResourceManager狀態儲存

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

• 基於記憶體實現，一般是用於日常開發測試。
• 基於檔案系統的實現，如HDFS。
• 基於ZooKeeper實現。

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

[zk: localhost:2181(CONNECTED) 28] ls /rmstore/ZKRMStateRoot [RMAppRoot, AMRMTokenSecretManagerRoot, EpochNode, RMDTSecretManagerRoot, RMVersionNode]

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

小結：

ZooKeepr在Hadoop中的應用主要有：

1. HDFS中NameNode的HA和YARN中ResourceManager的HA。
2. 儲存RMStateStore狀態資訊

ZooKeeper在HBase中的應用

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

HMaster選舉與主備切換

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

系統容錯

當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就成了理想的選擇。

RootRegion管理

對應HBase叢集來說，資料儲存的位置資訊是記錄在後設資料region，也就是RootRegion上的。每次客戶端發起新的請求，需要知道資料的位置，就會去查詢RootRegion，而RootRegion自身位置則是記錄在ZooKeeper上的（預設情況下，是記錄在ZooKeeper的/hbase/meta-region-server節點中）。當RootRegion發生變化，比如Region的手工移動、重新負載均衡或RootRegion所在伺服器發生了故障等是，就能夠通過ZooKeeper來感知到這一變化並做出一系列相應的容災措施，從而保證客戶端總是能夠拿到正確的RootRegion資訊。

Region管理

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

在下線期間資料是不能被訪問的，並且Region的這個狀態變化必須讓全域性知曉，否則可能會出現事務性的異常。對於大的HBase叢集來說，Region的數量可能會多達十萬級別，甚至更多，這樣規模的Region狀態管理交給ZooKeeper來做也是一個很好的選擇。

分散式SplitWAL任務管理

當某臺RegionServer伺服器掛掉時，由於總有一部分新寫入的資料還沒有持久化到HFile中，因此在遷移該RegionServer的服務時，一個重要的工作就是從WAL中恢復這部分還在記憶體中的資料，而這部分工作最關鍵的一步就是SplitWAL，即HMaster需要遍歷該RegionServer伺服器的WAL，並按Region切分成小塊移動到新的地址下，並進行日誌的回放（replay）。

由於單個RegionServer的日誌量相對龐大（可能有上千個Region，上GB的日誌），而使用者又往往希望系統能夠快速完成日誌的恢復工作。因此一個可行的方案是將這個處理WAL的任務分給多臺RegionServer伺服器來共同處理，而這就又需要一個持久化元件來輔助HMaster完成任務的分配。當前的做法是，HMaster會在ZooKeeper上建立一個SplitWAL節點（預設情況下，是/hbase/SplitWAL節點），將“哪個RegionServer處理哪個Region”這樣的資訊以列表的形式存放到該節點上，然後由各個RegionServer伺服器自行到該節點上去領取任務並在任務執行成功或失敗後再更新該節點的資訊，以通知HMaster繼續進行後面的步驟。ZooKeeper在這裡擔負起了分散式叢集中相互通知和資訊持久化的角色。

小結：

以上就是一些HBase中依賴ZooKeeper完成分散式協調功能的典型場景。但事實上，HBase對ZooKeepr的依賴還不止這些，比如HMaster還依賴ZooKeeper來完成Table的enable/disable狀態記錄，以及HBase中幾乎所有的後設資料儲存都是放在ZooKeeper上的。

由於ZooKeeper出色的分散式協調能力及良好的通知機制，HBase在各版本的演進過程中越來越多地增加了ZooKeeper的應用場景，從趨勢上來看兩者的交集越來越多。HBase中所有對ZooKeeper的操作都封裝在了org.apache.hadoop.hbase.zookeeper這個包中，感興趣的同學可以自行研究。

參考

• 《從Paxos到Zookeeper》
• http://linbingdong.com/2017/01/10/ZooKeeper%E5%8E%9F%E7%90%86%E5%8F%8A%E5%85%B6%E5%9C%A8Hadoop%E5%92%8CHBase%E4%B8%AD%E7%9A%84%E5%BA%94%E7%94%A8/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31383567/viewspace-2145064/，如需轉載，請註明出處，否則將追究法律責任。