hbase源码系列(三)Client如何找到正确的Region Server-阿里云开发者社区

开发者社区> 岑玉海> 正文

hbase源码系列(三)Client如何找到正确的Region Server

简介: Client如何找到正确的Region Server ?
+关注继续查看

客户端在进行put、delete、get等操作的时候,它都需要数据到底存在哪个Region Server上面,这个定位的操作是通过HConnection.locateRegion方法来完成的。

loc = hConnection.locateRegion(this.tableName, row.getRow());
这里我们首先要讲hbase的两张元数据表-ROOT-和.META.表,它们一个保存着region的分部信息,一个保存着region的详细信息。在《hbase实战》这本书里面详细写了查找过程总共有8步:

1)客户端首先查询zookeeper -ROOT-表在哪里

2)zookeeper告诉客户端,-ROOT-在RegionServer RS1上面

3)客户端向RS1发起查询,哪一个.META表可以查到T1表里面的00009

4)RS1上的-ROOT-告诉客户端在RS3上面的.META. region M2可以找到

5)客户端向RS3上的.META. region M2查询T1表的00009行数据在哪个region上,哪一个Region Server可以提供服务

6)RS3告诉客户端,在RS3上面的region T1R3

7)客户端向RS3上面的region T1R3发起请求,我要读取00009行

8)RS3上的region T1R3把数据发给客户端,行,拿去吧

那在代码里面是怎么体验上述过程的呢?好,我们开始查看locateRegion这个方法,打开HConnectionManager这个类。

private HRegionLocation locateRegion(final TableName tableName,
      final byte [] row, boolean useCache, boolean retry) {
      if (tableName.equals(TableName.META_TABLE_NAME)) {
        return this.registry.getMetaRegionLocation();
      } else {
        // Region not in the cache - have to go to the meta RS
        return locateRegionInMeta(TableName.META_TABLE_NAME, tableName, row,
          useCache, userRegionLock, retry);
      }
}
TableName.META_TABLE_NAME,这个就是我们要找的-ROOT-,在0.96里面它已经被取消了,取而代之的是META表中的第一个regionHRegionInfo.FIRST_META_REGIONINFO,它位置在zk的meta-region-server节点当中的。

好吧,再回到代码里面,我们这里肯定是走else这个路径,我们进入locateRegionInMeta看看。代码好长啊,我们一点一点看吧,先从缓存里面找,把tableName和rowkey传进去。

if (useCache) {
    location = getCachedLocation(tableName, row);
    if (location != null) {
       return location;
    }
}
这里的cache是这样组织的Map<tableName, SoftValueSortedMap<rowkey, HRegionLocation>>, 通过tableName获得它的基于rowkey的子map,这个map是按照key排好序的,如果找不到合适的key,就找比它稍微小一点的key。

接下来就是一个for循环了,默认是尝试31次。

HRegionLocation metaLocation = null;
        try {
          // locate the meta region 还好这个不是玩递归,直接获取meta表所在的位置
          metaLocation = locateRegion(parentTable, metaKey, true, false);
          if (metaLocation == null) continue;
      // 通过这方法可以获得Region Server,超值啊
          ClientService.BlockingInterface service = getClient(metaLocation.getServerName());
      synchronized (regionLockObject) 
          if (useCache) {
              location = getCachedLocation(tableName, row);
              if (location != null) {
                return location;
              }
        // 如果表没有被禁用,就预加载缓存
        if (parentTable.equals(TableName.META_TABLE_NAME)
                  && (getRegionCachePrefetch(tableName))) {
                prefetchRegionCache(tableName, row);
              }
        // 如果缓存中有,就从缓存中取
              location = getCachedLocation(tableName, row);
              if (location != null) {
                return location;
              }
          }else {
        // 不需要缓存就在缓存中删掉
              forceDeleteCachedLocation(tableName, row);
            
      }

从上面的代码分析,它在prefetchRegionCache方法预先缓存了和表和row相关的位置信息,核心的代码如下:

MetaScannerVisitor visitor = new MetaScannerVisitorBase() {
        public boolean processRow(Result result) throws IOException {
        // 把result转换为regionInfo
       HRegionInfo regionInfo = MetaScanner.getHRegionInfo(result);
            long seqNum = HRegionInfo.getSeqNumDuringOpen(result);
            HRegionLocation loc = new HRegionLocation(regionInfo, serverName, seqNum);
            // cache this meta entry
            cacheLocation(tableName, null, loc);
            return true;
        }
      };  MetaScanner.metaScan(conf, this, visitor, tableName, row, this.prefetchRegionLimit, TableName.META_TABLE_NAME);

这里面的核心代码只有两行,实现一个MetaScannerVisitor,然后传入到MetaScanner.metaScan扫描一下,metaScan会调用visiter的processRow方法,processRow方法把满足条件的全都缓存起来。下面是条件,有兴趣的人可以看一下,我折叠起来。

HRegionInfo regionInfo = MetaScanner.getHRegionInfo(result);
            if (regionInfo == null) {
              return true;
            }

            // possible we got a region of a different table...
            if (!regionInfo.getTable().equals(tableName)) {
              return false; // stop scanning
            }
            if (regionInfo.isOffline()) {
              // don't cache offline regions
              return true;
            }

            ServerName serverName = HRegionInfo.getServerName(result);
            if (serverName == null) {
              return true; // don't cache it
            }

看一下MetaScanner.metaScan吧,它也是用了new了一个HTable。

HTable metaTable = new HTable(TableName.META_TABLE_NAME, connection, null);
然后根据有三种情况,根据情况来构建Scan的StartKey:

1.根据rowkey来扫描

2.全表扫

3.根据表的名来

这里讲一下根据rowkey来扫描吧,别的都很简单,它用的是HTable的getRowOrBefore来找到这个Row,只不过因为它是meta表,可以从zk上直接找到位置。

byte[] searchRow = HRegionInfo.createRegionName(tableName, row, HConstants.NINES, false);
Result startRowResult = metaTable.getRowOrBefore(searchRow, HConstants.CATALOG_FAMILY);
HRegionInfo regionInfo = getHRegionInfo(startRowResult);
byte[] rowBefore = regionInfo.getStartKey();
startRow = HRegionInfo.createRegionName(tableName, rowBefore, HConstants.ZEROES, false);

下面就开始Scan了,这个Scan的代码,和我们平常用HTable来扫描表是一样的。

final Scan scan = new Scan(startRow).addFamily(HConstants.CATALOG_FAMILY);
      int rows = Math.min(rowLimit, configuration.getInt(HConstants.HBASE_META_SCANNER_CACHING,
        HConstants.DEFAULT_HBASE_META_SCANNER_CACHING));
      scan.setCaching(rows);
      // Run the scan
      scanner = metaTable.getScanner(scan);
      Result result = null;
      int processedRows = 0;
      while ((result = scanner.next()) != null) {
     // 用visitor.processRow来过滤不符合的result
        if (visitor != null) {
          if (!visitor.processRow(result)) break;
        }
        processedRows++;
        if (processedRows >= rowUpperLimit) break;
      }

如果没用缓存的情况,就只能走接口的方式了,直接从服务器去了,如果这都找不着,这一次就算结束了。

regionInfoRow = ProtobufUtil.getRowOrBefore(service,metaLocation.getRegionInfo().getRegionName(), metaKey, HConstants.CATALOG_FAMILY);

// 下面是具体的实现
GetRequest request = RequestConverter.buildGetRowOrBeforeRequest(regionName, row, family);
GetResponse response = client.get(null, request);
if (!response.hasResult()) return null;
return toResult(response.getResult());
好,现在最后总结一下吧:

1)要查询数据时候,在locateRegion方法要先走locateRegionInMeta这段

2)从zk当中获取meta表的位置,通过这个位置信息ServerName,获得Region Server的接口,但是这里先不用,留给不用缓存的情况用的

3)使用缓存的话,如果这个表没被禁用,就先把要定位的整个表的region的位置信息,全部缓存起来

4)在缓存表的过程当中,我们要借助new HTable(TableName.META_TABLE_NAME, connection, null)来计算startKey和扫描。

5)把扫描到的表相关的位置信息缓存起来,缓存之后取的过程这里忘了交代了,通过表名找到表对应的一个HRegionInfo,HRegionInfo里面包括startKey和stopKey,用rowkey一比对就知道是哪个region了。

6)不用缓存的情况,就走接口的方式,构造一个GetRequest,调用Region Server里面的get方法获取到位置信息。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
darwin Stream Server源码分析
摘要 ​所谓的流式媒体简单的讲就是指人们通过网络实时的收看多媒体信息:如音频流、视频流等。与流式媒体对应的传统工作方式是下载+播放模式,即用户首先下载多媒体文件,然后再在本地播放,这种方法的一个主要缺点是启动延迟较大,例如一个30分钟长的MPEG-I文件(相当于VCD质量),即使使用1.5Mbps的速率下载,也需要半个小时才能完成,这样一个漫长的等待时间实在是无法忍受。
1184 0
hbase源码系列(四)数据模型-表定义和列族定义的具体含义
hbase是一个KeyValue型的数据库,在《hbase实战》描述它的逻辑模型【行键,列族,列限定符,时间版本】,物理模型是基于列族的。但实际情况是啥?还是上点代码吧。
2434 0
OPC Client 核心源码
好像技术一沾上工业,便有了很高的价值,大家三缄其口,谁都不点破这层窗户纸,好多的思路和源码都要从国外网站获得,国内总是有条件,有限制--就是不告诉你,怕教会徒弟,饿死师父吧。
702 0
hbase源码系列(五)Trie单词查找树
在hbase当中单独拿了一个工程出来实现了Trie的数据结果,既达到了压缩编码的效果,亦达到了方便查询的效果,一举两得,设置的方法是在上一章的末尾提了。
1479 0
hbase源码系列(七)Snapshot的过程
本文讲解Snapshot的过程 ,在看这一章之前,建议大家先去看一下snapshot的使用。
2485 0
hbase源码系列(六)HMaster启动过程
这一章是server端开始的第一章,有兴趣的朋友先去看一下hbase的架构图,我专门从网上弄下来的。
1706 0
hbase源码带注释版本,放在这里,方便大家下载吧
看了5个月的hbase源码,记录了一些笔记,如果有需要的朋友可以拿去。
1757 0
追本溯源 - Eclipse源码窥探
        最近花时间解决了一些以前积攒的,未曾深入研究的问题。其中一个就是eclipse maven 关联jar包源代码出现乱码的问题。问题的解决方案不算太麻烦,但是追本溯源确是件很有意思的事情(一直追踪到eclipse的源代码,探查到一些开源项目,如:伊利诺斯大学的开源项目CodingSpectator)。当然了,RCP开发本身就挺吸引我的,后面有机会,会和大家分享更多的心得。好了
914 0
hbase源码系列(二)HTable 探秘
hbase的源码终于搞一个段落了,继上一篇讲了负载均衡之后,这一篇我们从client开始讲吧,从client到master再到region server,按照这个顺序来开展,读者们也可以对自己感兴趣的部分给我留言或者直接联系我。
1789 0
hbase源码系列(三)Client如何找到正确的Region Server
Client如何找到正确的Region Server ?
2014 0
+关注
64
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载