HBase依賴Zookeeper原因分析

本篇內容介紹了“HBase依賴Zookeeper原因分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一、ZooKeeper相關知識：

概念：

  Zookeeper是一個分布式應用程序協調服務，提供了簡單易用的接口和性能高效、功能穩定的系統讓用戶可以很輕松解決分布式應用程序下面的出現的協調服務，確保避免出現競態條件或者死鎖等錯誤。其設計目標是減輕分布式應用從零開始實現分布式協調服務的壓力。

    假設我們的程序是分布式部署在多臺機器上，如果我們要改變程序的配置文件，需要逐臺機器去修改，非常麻煩，現在把這些配置全部放到zookeeper上去，保存在 zookeeper 的某個目錄節點中，然后所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 zookeeper 的通知，然后從 zookeeper 獲取新的配置信息應用到系統中。

數據節點(znode)：

    Zookeeper維護一個類似文件系統的數據結構，每一個節點是指數據模型中的數據單元，稱為ZNode。ZooKeeper將所有數據存儲在內存中，數據模型是一棵樹（ZNode Tree），由斜杠（/）進行分割的路徑，就是一個ZNode，如/hbase-unsecure/replication,其中hbase-unsecure和replication都是ZNode。每個ZNode上都會保存自己的數據內容，同時會保存一系列屬性信息。每個znode由三部分組成。

• stat：狀態信息，描述該znode的版本，權限等信息

• data：與該znode關聯的數據

• children：該znode下的子節點

zkCli.sh使用：

    ZooKeeper提供了一個交互式shell，允許各種Znode操作，就像在典型的文件系統中一樣。還可以使用get命令獲得關于znode內容的一些信息。

兩種方式：

#hbase命令直接登錄[hbase@salver158 ~]$ hbase zkcli

#zookeeper客戶端腳本登錄[hbase@salver158 ~]$ /usr/hdp/2.6.3.0-235/zookeeper/bin/zkCli.sh -server salver158.hadoop.unicom:2181

    zkCli客戶端中輸入 help 命令（其實輸入任何 zkCli 不能識別的命令，都會列出所有的命令），查看可用的命令：

[zk: salver158.hadoop.unicom:2181(CONNECTED) 0] helpZooKeeper -server host:port cmd args  stat path [watch]  set path data [version]  ls path [watch]  delquota [-n|-b] path  ls2 path [watch]  setAcl path acl  setquota -n|-b val path  history   redo cmdno  printwatches on|off  delete path [version]  sync path  listquota path  rmr path  get path [watch]  create [-s] [-e] path data acl  addauth scheme auth  quit   getAcl path  close   connect host:port

有幾個比較重要的命令我這里結合HBase的znode簡單說一下，其他命令請自行百度：

1. create：在樹中的某個位置創建一個節點。
   

2. delete：刪除一個節點。
   

3. exists：測試一個節點是否存在。
   

4. get data：讀取節點數據。
   

5. set data：向節點中寫入數據。
   

6. get children：檢索某節點的子節點列表。
   

7. sync：等待要傳播的數據。

這里專門說下get path 獲取節點信息

[zk: salver158.hadoop.unicom:2181(CONNECTED) 3] get /hbase-unsecure cZxid = 0x1a005eda9b   //每個znode被賦予一個全局唯一的ID，我們稱之為zxidctime = Thu Aug 15 14:46:01 CST 2019 //znode創建時間mZxid = 0x1a005eda9b      //mtime = Thu Aug 15 14:46:01 CST 2019 //znode最后一次修改時間pZxid = 0x2100398049  //最后一次修改該znode子節點的 zxidcversion = 89   //該節點子節點的版本dataVersion = 0 //該節點內容的版本，每次修改內容，版本都會增加aclVersion = 0  //該節點的 ACL 版本ephemeralOwner = 0x0  //如果該節點是臨時節點（ephemeral node），會列出該節點所在客戶端的 session id；如果不是臨時節點，該值為 0dataLength = 0  //該節點存儲的數據長度numChildren = 17  //該節點子節點的個數

 另外一個命令：sync path

sync方法會強制客戶端所連接的服務器狀態與leader的狀態同步，這樣在讀取 path 的值就是最新的值了。

二、hbase與zookeeper的關系

    HBase主要用ZooKeeper來實現HA選舉與主備集群主節點的切換、系統容錯、RootRegion管理、Region狀態管理和分布式SplitWAL任務管理等。

1).HA管理：

    集群的主節點的選舉和主備的切換跟Hadoop中Namnode的HA的選舉和切換機制類似（后面我會專門寫一篇文章講解Namenode的HA）。

2).RegionServer管理：

    HBase集群啟動時，每臺RegionServer在Zookeeper中/hbase-unsecure/rs注冊一個自己的臨時節點，HMaster會利用這些臨時節點來發現可用RegionServer，還可以利用臨時節點來跟蹤及其故障和網絡分區。這些臨時節點相當于一個“會話”，會話是客戶端鏈接上Zookeeper服務器之后自動生成的。每個會話有一個唯一的id，RegionServer會用這個id不斷向Zookeeper服務器發送“心跳”，一旦RegionServer發生故障，發送心跳則會停止，當超過限定時間后，Zookeeper服務器會判定會話超時，并自動刪除屬于它的臨時會話。與此同時，HMaster 則會接收到 ZooKeeper 的 NodeDelete 通知，從而感知到某個節點斷開，并立即開始容錯工作。

   備注：

       為啥選擇zookeeper干這個事？因為隨著集群節點越來越多，HMaster的管理負擔會越來越重，另外它自身也有掛掉的可能，因此數據還需要持久化，zookeeper通常是一個集群，這樣穩定性相對就高了很多。

3).元數據Region：

    每次客戶端向HBase發起請求時，都會去查詢元數據Region,默認目錄是：

/hbase-unsecure/meta-region-server,如果發生region的遷移，zookeeper都會進行試試更新，以便其他客戶端請求時，總能查到最新的RootRegion信息。

4).Region管理：

    的狀態經常會發生變更，比如Region遷移、上線、離線，都是通過zookeeper來統一管理的。

5).預寫日志恢復

    RegionServer經常會通過WAL預寫日志進行數據的恢復，由于RegionServer數據量比較大，單個節點進行恢復速度比較慢，HMaster會把WAL預寫日志進行切分，放到Zookeeper的/hbase-unsecure/splitWAL目錄中，讓其他的RegionSever都能參與日志的恢復工作，提升恢復速度。ZooKeeper在這里擔負起了分布式集群中相互通知和信息持久化的角色。

三、HBase的znode

    HBase在zookeeper的znode的根節點是通過hbase-site.xml中的“zookeeper.znode.parent”屬性進行配置的（/hbase-unsecure），每次HBase集群重啟znode都會重建，所以如果集群重啟的話，重啟之前直接刪除/hbase-unsecure也是沒有問題的。下面就具體講解下HBase在ZooKeeper中znode目錄結構：

replication：

meta-region-server：

    HBase元數據表Region位置信息，在哪個Regionsever上;

rs：

        RS的臨時節點,應該是只有在線RegionServer節點，宕機、掉線沒有。

splitWAL：

    WAL預寫分割工作分配目錄

backup-masters:

    備用HMaster節點

table-lock:    

       表鎖節點會有所有表

flush-table-proc:

    flush進程

region-in-transition:

    處于RIT狀態的region

online-snapshot:

   快照

master:

    激活HMaster節點

balancer:

    正在進行balance的節點

recovering-regions:

    正在恢復的region

namespace：

     HBase集群所有命名空間

hbaseid：

    HBase集群的唯一ID

table：

    集群中各個表信息

“HBase依賴Zookeeper原因分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！