原文鏈接：https://blog.csdn.net/mingyuezh/article/details/80844925
Region定位：
系統如何找到某個row key (或者某個 row key range)所在的region?
關於Region的查找，早期的設計（0.96.0）之前是被稱之為三層查詢架構，如下圖所示：
Region：就是要查找的數據所在的Region
.META.：是一張元數據表，記錄了用戶表的Region信息以及RegionServer的服務器地址，.META.可以有多個regoin。.META.表中的一行記錄就是一個Region，
記錄了該Region的起始行、結束行和該Region的連接信息。
-ROOT-：是一張存儲.META.表的表，記錄了.META.表的Region信息，-ROOT-只有一個region
Client訪問用戶數據之前需要首先訪問zookeeper，然后訪問-ROOT-表，接着訪問.META.表，最后才能找到用戶數據的位置去訪問，中間需要多次網絡操作，
不過client端會做cache緩存。
步驟：
（1）用戶通過查找zk（zookeeper）的/hbase/root-region-server節點來知道-ROOT-表在什么RegionServer上。
（2）訪問-ROOT-表，查看需要的數據在哪個.META.表上，這個.META.表在什么RegionServer上。
（3）訪問.META.表查看查詢的行健在什么Region范圍里面。
（4）連接具體的數據所在的RegionServer，這回就真的開始用Scan來遍歷row了。
說明：
.META.表每行保存一個region的位置信息，row key 采用表名+表的最后一樣編碼而成。
為了加快訪問，.META.表的全部region都保存在內存中。
假設，.META.表的一行在內存中大約占用1KB。並且每個region限制為128MB。
那么上面的三層結構可以保存的region數目為：
(128MB/1KB) * (128MB/1KB) = = 2^32個region
Client會將查詢過的位置信息保存緩存起來，緩存不會主動失效，因此如果client上的緩存全部失效，則需要進行6次網絡來回，
才能定位到正確的region(其中三次用來發現緩存失效，另外三次用來獲取位置信息)。
實際上.META.表一直就只有一個，所以-ROOT-中的記錄一直都只有一行，-ROOT-表形同虛設。而且，三層機構增加了代碼的復雜度，容易產生BUG。
從0.96版本以后，三層架構被改為二層架構，-ROOT-表被去掉了，同時zk中的/hbase/root-region-server也被去掉了。直接把.META.表所在的RegionServer信息存儲
到了zk中的/hbase/meta-region-server去了。再后來引入了namespace，.META.表這樣別扭的名字被修改成了hbase:meta。
二層架構的定位步驟如下：
（1）用戶通過查找zk（zookeeper）的/hbase/meta-region-server節點查詢哪台RegionServer上有hbase:meta表。
（2）客戶端連接含有hbase:meta表的RegionServer。Hbase:meta表存儲了所有Region的行健范圍信息，通過這個表就可以查詢出你要存取的rowkey屬於
哪個Region的范圍里面，以及這個Region又是屬於哪個RegionServer。
（3）獲取這些信息后，客戶端就可以直連其中一台擁有你要存取的rowkey的RegionServer，並直接對其操作。
（4）客戶端會把meta信息緩存起來，下次操作就不需要進行以上加載HBase:meta的步驟了。