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這個包中，感興趣的同學可以自行研究。
閱讀更多 加米穀大數據 的文章
