hbase源码系列(三)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方法获取到位置信息。
hbase源码系列(三)Client如何找到正确的Region Server的更多相关文章
- 三 Client 如何找到正确的 Region Server
客户端在进行put.delete.get等操作的时候,它都需要数据到底存在哪个Region Server上面,这个定位的操作是通过 Connection.locateRegion方法来完成的. loc ...
- hbase源码系列(二)HTable 探秘
hbase的源码终于搞一个段落了,在接下来的一个月,着重于把看过的源码提炼一下,对一些有意思的主题进行分享一下.继上一篇讲了负载均衡之后,这一篇我们从client开始讲吧,从client到master ...
- hbase源码系列(十二)Get、Scan在服务端是如何处理
hbase源码系列(十二)Get.Scan在服务端是如何处理? 继上一篇讲了Put和Delete之后,这一篇我们讲Get和Scan, 因为我发现这两个操作几乎是一样的过程,就像之前的Put和Del ...
- 9 hbase源码系列(九)StoreFile存储格式
hbase源码系列(九)StoreFile存储格式 从这一章开始要讲Region Server这块的了,但是在讲Region Server这块之前得讲一下StoreFile,否则后面的不好讲下去 ...
- 11 hbase源码系列(十一)Put、Delete在服务端是如何处理
hbase源码系列(十一)Put.Delete在服务端是如何处理? 在讲完之后HFile和HLog之后,今天我想分享是Put在Region Server经历些了什么?相信前面看了<HTab ...
- 10 hbase源码系列(十)HLog与日志恢复
hbase源码系列(十)HLog与日志恢复 HLog概述 hbase在写入数据之前会先写入MemStore,成功了再写入HLog,当MemStore的数据丢失的时候,还可以用HLog的数据来进行恢 ...
- HBase源码系列之HFile
本文讨论0.98版本的hbase里v2版本.其实对于HFile能有一个大体的较深入理解是在我去查看"到底是不是一条记录不能垮block"的时候突然意识到的. 首先说一个对HFile ...
- hbase源码系列(十二)Get、Scan在服务端是如何处理?
继上一篇讲了Put和Delete之后,这一篇我们讲Get和Scan, 因为我发现这两个操作几乎是一样的过程,就像之前的Put和Delete一样,上一篇我本来只打算写Put的,结果发现Delete也可以 ...
- Spring源码系列(三)--spring-aop的基础组件、架构和使用
简介 前面已经讲完 spring-bean( 详见Spring ),这篇博客开始攻克 Spring 的另一个重要模块--spring-aop. spring-aop 可以实现动态代理(底层是使用 JD ...
随机推荐
- Hive实现从表中随机抽样得到一个不重复的数据样本
select a.* from ( select a.*,rand(12345) as random from tripdata a ) a where random between 0 and 0. ...
- JQ:命令行 json 解析神器 —— 命令行的Jsonview
- 用 Fiddler 来弥补 Chrome Network 的小缺点
由于经常要查看后端的接口详情,但Chrome控制台的Network并不会全显api路径,而且每次需要先启动控制台,再进行请求才能记录到.大多数情况下都是要刷新页面,这会浪费很多时间. 还不如开一个 F ...
- extjs4学习-01-准备工作
想学习这个,在这里做个笔记. 创建了svn管理,路径http://ip:端口/repos/doc_jnfwz/liuzhenming/extjs4/extjs4 eclipse 中安装插件,支持在js ...
- mysql-8.0.11 比较坑的地方dba门要淡定
[事件描述] 突然之间大量的连接进入数据库.并放开手干,这个使得mysql使用了大量的内存,触发了linux的oom机制.然后mysql就这样 被linux给干掉了.没错MySQL宕机了,要相信我说的 ...
- WPF 程序在 Windows XP 下报错:The image format is unrecognized.
最近做的一个 WPF 程序,在 Windows 7 或以上版本的系统中,测试都很正常,在 Windows XP 下运行时一开始就报了个错误: { "ClassName" : ...
- C#实现RSA加密与解密、签名与认证
一.RSA简介 RSA公钥加密算法是1977年由Ron Rivest.Adi Shamirh和LenAdleman在(美国麻省理工学院)开发的.RSA取名来自开发他们三者的名字.RSA是目前最有影响力 ...
- Bootstrap FileInput中文API整理
这段时间做项目用到bootstrap fileinput插件上传文件,在用的过程中,网上能查到的api都不是很全,所以想着整理一份比较详细的文档,方便自己今后使用,也希望能给大家带来帮助,如有错误,希 ...
- hdu Constructing Roads (最小生成树)
题目:http://acm.hdu.edu.cn/showproblem.php?pid=1102 /************************************************* ...
- (转)CTP: 平昨仓与平今仓,log轻轻告诉你.......
转自:http://blog.csdn.net/wowotuo/article/details/43242663 CTP的相关文档告诉我们,中金所和三大商品交易所中,只有上期所区分平今仓和平昨仓.也就 ...