ZooKeeper典型應用場景

轉自：http://blog.jobbole.com/110388/

    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(Hive Availability），包括HDFS的NamaNode和YARN的ResourceManager的HA。同時，在YARN中，ZooKeepr還用來存儲應用的運行狀態。HDFS的NamaNode和YARN的ResourceManager利用ZooKeepr實現HA的原理是一樣的，所以本節以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. 1. 創建鎖節點
      在ZooKeeper上會有一個/yarn-leader-election/appcluster-yarn的鎖節點，所有的ResourceManager在啟動的時候，都會去競爭寫一個Lock子節點：/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb，該節點是臨時節點。ZooKeepr能夠為我們保證最終只有一個ResourceManager能夠創建成功。創建成功的那個ResourceManager就切換為Active狀態，沒有成功的那些ResourceManager則切換為Standby狀態。
      
       

       

      1 2 3 4 5 6 7 8 9 10 11 12 13

      [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. 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這個根節點下面。

 

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

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

小結：

ZooKeepr在Hadoop中的應用主要有：

1. 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這個包中，感興趣的同學可以自行研究。