ZooKeeper作為分布式協調組件，在大數據領域的其他分布式組件中往往扮演著重要的輔助角色，因此我們就算不單獨去研究ZooKeeper，也短不了要接觸它。本文就以最典型的HBase為例，簡要介紹ZooKeeper為HBase提供了哪些功能。

下圖示出一個完整HBase集群的架構，其中包含ZK節點。

HMaster、RegionServer容錯

當HBase集群啟動成功后，會在ZK注冊如下znode：

• /hbase/master，其中包含當前活動（即贏得選舉）的HMaster信息；
• /hbase/backup-masters/[host-name]，每個子znode包含當前作為熱備的HMaster信息；
• /hbase/rs/[host-name]，每個子znode包含各RegionServer的信息。

所有znode都是臨時（ephemeral）節點，HMaster和RegionServer通過心跳維護這些znode。活動HMaster對/hbase/rs路徑下的znode注冊監聽，當有RegionServer失敗時，心跳信號消失，超時過后其對應的znode被刪除，HMaster即可感知到RegionServer下線，并將該RegionServer持有的Region重新路由到其他服務器上去。同理，所有熱備HMaster都對/hbase/master節點注冊監聽，當前HMaster掛掉后，該znode被刪除，即可觸發重新選舉HMaster。如下圖所示。

Log Split管理

當RegionServer宕機時，除了重新路由Region之外，還得從宕機的RegionServer的WAL（即HLog）中恢復尚未持久化到HFile的數據。為了保證盡快完成failover過程，HBase會將HLog按Region切分成多個分片，并分配給對應的存活RegionServer再完成重放（replay）過程。如下圖所示。

顯然，Log Split的信息需要有一個中心組件來統一協調。HMaster會在ZK上注冊/hbase/splitlog臨時節點，其中存放有存活RegionServer與其應該處理的Region HLog的映射關系。各個RegionServer從該節點得到分配的Region，重放HLog，并將結果寫回該節點，以通知HMaster進行后續操作。

.META.表位置維護

HBase中有一個特殊的表.META.（在0.98版本之前還有一個-ROOT-表，現已廢棄，不再介紹），其中以類似B樹的結構記錄了集群內所有Region的位置信息，且該表不會split。而ZK通過永久（persistent）節點/hbase/meta-region-server來記錄.META.表保存在哪個RegionServer上。

當客戶端初次與HBase集群建立連接時，它首先查詢上述ZK節點，再從持有.META.表的RegionServer獲取到RowKey對應的Region位置信息并緩存起來，最后獲取到對應的行做讀寫操作。如下圖所示。

如果Region被移動，或客戶端緩存失效，甚至.META.表所在的服務器故障，客戶端總能通過ZK維護的路徑獲得正確的Region位置，不會造成不一致。

Replication管理

HBase的Replication是比較高級的功能，用于主集群和從集群之間的數據同步，從而支持容災和備份。開啟Replication之后，主集群會將數據實時地推送給各個從集群（可以是異步、同步或串行的），且保證數據的最終一致性。整個Replication的狀態信息都儲存在ZK的/hbase/replication這個znode下，主要有以下三個：

• /hbase/replication/state：布爾值，表示Replication是否被啟用；
• /hbase/replication/peers：當前進行Replication的從集群對及其狀態。每個peer會分配一個唯一ID；
• /hbase/replication/rs：包含主集群上所有有效的RegionServer、 HLog文件的索引，以及HLog讀取的偏移量。

主集群HMaster每次將新增的數據推送給從集群之后，就會更新ZK上記錄的這些信息，以協調Replication的進度。

多個HBase集群是可以共用一個ZK集群的。只需要修改HBase的zookeeper.znode.parent參數，對不同集群指定不同的ZK根路徑即可，例如/hbase-cluster1、/hbase-cluster2，etc。

總結

以上是生活随笔為你收集整理的ZooKeeper在HBase集群中的作用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。