谈谈HTable的实现

最新推荐文章于 2022-11-17 23:31:52 发布

pwlazy

最新推荐文章于 2022-11-17 23:31:52 发布

阅读量1.2w

点赞数 3

CC 4.0 BY-SA版权

分类专栏： hbase 文章标签： server cache string byte table hbase

本文链接：https://blog.youkuaiyun.com/pwlazy/article/details/7417135

hbase 专栏收录该内容

8 篇文章

订阅专栏

本文通过一个简单的示例介绍了HTable在HBase中的实现机制，包括HTable的初始化过程、如何与Zookeeper交互获取RegionServer信息，以及HTable进行数据读取的具体流程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

HTable作为HBase的CRUD的客户端底层是怎么实现的，虽然HBase-The-Definitive-Guide 这本书的作者推荐在生产环境使用HTablePool
但了解HTable还是很有必要的

下面以一个简单的例子来说明

protected static String TEST_TABLE_NAME = "testtable";
 protected static String ROW1_STR = "row1";
 protected static String COLFAM1_STR = "colfam1";
 protected static String QUAL1_STR = "qual1";
 private final static byte[] ROW1 = Bytes.toBytes(ROW1_STR);
 private final static byte[] COLFAM1 = Bytes.toBytes(COLFAM1_STR);
 private final static byte[] QUAL1 = Bytes.toBytes(QUAL1_STR);

 @Test
 public void testHTable() throws IOException {

     Configuration conf = HBaseConfiguration.create();
     HTable table = new HTable(conf, TEST_TABLE_NAME);

     Get get = new Get(ROW1);
     Result result = table.get(get);
     byte[] val = result.getValue(COLFAM1, QUAL1);
     assertThat(Bytes.toString(val), is("val1"));
 }

代码非常简单，就是初始化HTable和调用HTable实例的get获取ROW1的值

在介绍下面的内容之前先简单的说下HBase server
HBase server 基本上由zookeeper和HRegion server组成
前者主要是用于监控和管理HRegion server，后者才是提供数据服务的
HRegion server又分为master+server，master用于维护meta信息，
master和server的确定使用了leader follow方式,任何HRegion server都有可能成为Master

HTable模型

HTable: 客户端API
HConnection: HTable对zookeeper的网络连接
ServerCallable:抽象一次和Region Server的交互，因此它需要有HConnection和HRegionLocation，同时需要有一个访问Region Server的接口
HRegionInterface HRegionLocation: Region Server的地址
HRegionInfo: Region Server的信息
HRegionInterface:访问Region Server的接口的动态代理
WritableRpcEngine$Invoker：动态代理的相关handle
HBaseClient:Region Server的客户端
其他的就不解释了

HTable runtime

1)HTable的初始化step1

初始化对zookeeper的连接
会调用zookeeper的api，启动两个线程，一个是sendthread,一个是eventhtread,
sendthread专门维护对zookeeper的连接，并且会监听zookeeper 的事件，比如节点变化的通知，一旦接到通知会将通知转发给eventhtread
eventhtread处理zookeeper的变化

2)HTable的初始化step2

从zookeeper获取到root HRegionLocation[region=-ROOT-,,0.70236052, hostname=localhost, port=33032] 并cache
从root HRegion中获取到meta HRegionLocation[region=.META.,,1.1028785192, hostname=localhost, port=33032] 并cache
从meta HRegion 取更多hregion信息缓存到本地（见HConnectionManager$HConnectionImplementation.prefetchRegionCache）
从meta HRegion中获取表所在的HRegionLocation[region=testtable,,1332256150817.5c8417fb964377174f649af04a70ad5e., hostname=localhost, port=33032]并cache

3) HTable.get到底干了什么

从cache中获取表对应的HRegionLocation
从cache中获取HRegionLocation对应的Region server【一个实现了HRegionInterface的动态代理，使用了WritableRpcEngine$Invoker作为InvocationHandler】
调用动态代理的get,解下来就会调用WritableRpcEngine$Invoker的invoke
调用HBaseClient.call

4)仔细看看HBaseClient.call

- 初始化一个Call实例（封装了请求和响应）
- 连接到Region server（见HBaseClient.getConnection）得到HBaseClient.Connection实例，此时会启动一个读线程（每个region一个），专门读取服务端的响应，也会将请求写入读线程的队列中
- 发请求，见【HBaseClient.Connection.sendParam(call)】，如果是多个请求线程，由于此时共用一个连接，还存在同步问题，且网络写也是阻塞的，写完了还得等通知
- 读线程会不断的读取响应，读取一个相应响应就将请求队列中对应的请求删除，并通知主线程即客户端线程，如果读线程空闲超时会自动回收
- 客户端线程和读线程采用传统的wait + notify 通信，这也意味着客户端线程会阻塞

小结

从HTable 的实现中看到了所谓的传说中的RPC到底是咋回事
- 一个服务接口
- 实现了服务接口的动态代理
- 动态代理对应的invoke handle
- 当然还有底层网络客户端
另外也看到的HTable的io模型
- 多个客户线程同步+阻塞写，并将写注册到读线程的队列中
- 单线程绑定单连接(基本上是每个region对应一个)，读取响应，删除队列中的请求标示，并通知客户线程
- 并没有使用NIO
- 和传统的连接池以及时髦的使用select的事件驱动比起来以及是一个比较怪异的实现