版權聲明：本文為博主原創文章，未經博主允許不得轉載。
HBase中的Client如何路由到正確的RegionServer
在HBase中，大部分的操作都是在RegionServer完成的，Client端想要插入，刪除，查詢數據都需要先找到相應的 RegionServer。什么叫相應的RegionServer？就是管理你要操作的那個Region的RegionServer。Client本身並 不知道哪個RegionServer管理哪個Region，那么它是如何找到相應的RegionServer的？本文就是在研究源碼的基礎上揭秘這個過程。
在前面的文章“HBase存儲架構”中我們已經討論了HBase基本的存儲架構。在此基礎上我們引入兩個特殊的概念：-ROOT-和.META.。這是什么？它們是HBase的兩張內置表，從存儲結構和操作方法的角度來說，它們和其他HBase的表沒有任何區別，你可以認為這就是兩張普通的表，對於普通表 的操作對它們都適用。它們與眾不同的地方是HBase用它們來存貯一個重要的系統信息——Region的分布情況以及每個Region的詳細信息。
好了，既然我們前面說到-ROOT-和.META.可以被看作是兩張普通的表，那么它們和其他表一樣就應該有自己的表結構。沒錯，它們有自己的表結構，並且這兩張表的表結構是相同的，在分析源碼之后我將這個表結構大致的畫了出來：
我們來仔細分析一下這個結構，每條Row記錄了一個Region的信息。
首先是RowKey，RowKey由三部分組成：TableName, StartKey 和 TimeStamp。RowKey存儲的內容我們又稱之為Region的Name。哦，還記得嗎？我們在前面的文章中提到的，用來存放Region的文件 夾的名字是RegionName的Hash值，因為RegionName可能包含某些非法字符。現在你應該知道為什么RegionName會包含非法字符 了吧，因為StartKey是被允許包含任何值的。將組成RowKey的三個部分用逗號連接就構成了整個RowKey，這里TimeStamp使用十進制 的數字字符串來表示的。這里有一個RowKey的例子：
Table1,RK10000,12345678
然后是表中最主要的Family：info，info里面包含三個Column：regioninfo, server, serverstartcode。其中regioninfo就是Region的詳細信息，包括StartKey, EndKey 以及每個Family的信息等等。server存儲的就是管理這個Region的RegionServer的地址。
所以當Region被拆分、合並或者重新分配的時候，都需要來修改這張表的內容。
到目前為止我們已經學習了必須的背景知識，下面我們要正式開始介紹Client端尋找RegionServer的整個過程。我打算用一個假想的例子來學習這個過程，因此我先構建了假想的-ROOT-表和.META.表。
我們先來看.META.表，假設HBase中只有兩張用戶表：Table1和Table2，Table1非常大，被划分成了很多Region，因此 在.META.表中有很多條Row用來記錄這些Region。而Table2很小，只是被划分成了兩個Region，因此在.META.中只有兩條Row 用來記錄。這個表的內容看上去是這個樣子的：
.META.
現在假設我們要從Table2里面插尋一條RowKey是RK10000的數據。那么我們應該遵循以下步驟：
1. 從.META.表里面查詢哪個Region包含這條數據。
2. 獲取管理這個Region的RegionServer地址。
3. 連接這個RegionServer, 查到這條數據。
好，我們先來第一步。問題是.META.也是一張普通的表，我們需要先知道哪個RegionServer管理了.META.表，怎么辦？有一個方法，我們把管 理.META.表的RegionServer的地址放到ZooKeeper上面不久行了，這樣大家都知道了誰在管理.META.。
貌似問題解決了，但對於這個例子我們遇到了一個新問題。因為Table1實在太大了，它的Region實在太多了，.META.為了存儲這些Region信 息，花費了大量的空間，自己也需要划分成多個Region。這就意味着可能有多個RegionServer在管理.META.。怎么辦？在 ZooKeeper里面存儲所有管理.META.的RegionServer地址讓Client自己去遍歷？HBase並不是這么做的。
HBase的做法是用另外一個表來記錄.META.的Region信息，就和.META.記錄用戶表的Region信息一模一樣。這個表就是-ROOT-表。這也解釋了為什么-ROOT-和.META.擁有相同的表結構，因為他們的原理是一模一樣的。
假設.META.表被分成了兩個Region，那么-ROOT-的內容看上去大概是這個樣子的：
-ROOT-
這么一來Client端就需要先去訪問-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。這個地址被存在ZooKeeper中。默認的路徑是：
/hbase/root-region-server
等等，如果-ROOT-表太大了，要被分成多個Region怎么辦？嘿嘿，HBase認為-ROOT-表不會大到那個程度，因此-ROOT-只會有一個Region，這個Region的信息也是被存在HBase內部的。
現在讓我們從頭來過，我們要查詢Table2中RowKey是RK10000的數據。整個路由過程的主要代碼在
- org.apache.hadoop.hbase.client.HConnectionManager.TableServers中：
- private HRegionLocation locateRegion(final byte [] tableName,
- final byte [] row, boolean useCache)
- throws IOException{
- if (tableName == null || tableName.length == 0) {
- throw new IllegalArgumentException(
- “table name cannot be null or zero length”);
- }
- if (Bytes.equals(tableName, ROOT_TABLE_NAME)) {
- synchronized (rootRegionLock) {
- // This block guards against two threads trying to find the root
- // region at the same time. One will go do the find while the
- // second waits. The second thread will not do find.
- if (!useCache || rootRegionLocation == null) {
- this.rootRegionLocation = locateRootRegion();
- }
- return this.rootRegionLocation;
- }
- } else if (Bytes.equals(tableName, META_TABLE_NAME)) {
- return locateRegionInMeta(ROOT_TABLE_NAME, tableName, row, useCache,
- metaRegionLock);
- } else {
- // Region not in the cache – have to go to the meta. RS
- return locateRegionInMeta(META_TABLE_NAME, tableName, row, useCache, userRegionLock);
- }
- }
這是一個遞歸調用的過程：
獲取Table2，RowKey為RK10000的RegionServer
=>
獲取.META.，RowKey為Table2,RK10000, 99999999999999的RegionServer
=>
獲取-ROOT-，RowKey為.META.,Table2,RK10000,99999999999999,99999999999999的RegionServer
=>
獲取-ROOT-的RegionServer
=>
從ZooKeeper得到-ROOT-的RegionServer
=>
從-ROOT-表中查到RowKey最接近（小於）
.META.,Table2,RK10000,99999999999999,99999999999999的一條Row，並得到.META.的RegionServer
=>
從.META.表中查到RowKey最接近（小於）Table2,RK10000, 99999999999999的一條Row，並得到Table2的RegionServer
=>
從Table2中查到RK10000的Row
到此為止Client完成了路由RegionServer的整個過程，在整個過程中使用了添加“99999999999999”后綴並查找最接近（小於）RowKey的方法。對於這個方法大家可以仔細揣摩一下，並不是很難理解。
最后要提醒大家注意兩件事情：
在整個路由過程中並沒有涉及到MasterServer，也就是說HBase日常的數據操作並不需要MasterServer，不會造成MasterServer的負擔。
Client端並不會每次數據操作都做這整個路由過程，很多數據都會被Cache起來。至於如何Cache，則不在本文的討論范圍之內。
引用：http://www.shangxueba.com/jingyan/tc454-1136.html