原文链接：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的步骤了。