白话HBase-客户端缓存 region位置信息

背景

第一次请求某个表的时候,table.get  table.scan 等api通常都比较慢,但是第一次慢了之后,后面有很快,是什么原因导致的呢?

我们直接从源码来看看

一般用户使用方法

HTableInterface table=connection.getTable(xxxx)

Get get=new Get(“zzz”.getBytes());

table.get(xxx);

代码分析

1.ConnectionManager  的getTable方法返回的实际是HTable

2.我们看看HTable的table.get方法做了什么呢? 

箭头部分是getLocation方法

点进去看看,return this.location;

看看这个location是哪里赋值的吧

3.右键看location在哪里被赋值

prepare方法和setLocation方法,前者在callable的callWithRetry中被调用,后者在walxxx才调用。那么看看前者prepare吧

// bad cache entries are cleared in the call to RetryingCallable#throwable() in catch block

callable.prepare(tries != 0); // if called with false, check table status on ZK

看来在重试机制下,第一次尝试运行,参数为false,后面几次参数为true

我们看看prepare到底干了啥

4.

5.

6. 再往下看

这里如果是第一次请求(不是重试),走后面第二个locateRegion方法,里面userCache=true =>getCachedLocation

如果是重试,走前面的relocateRegion方法,里面userCache=false

7.aaa

8.一路点下去 

9.继续

从缓存获取location的具体实现,metaCache类型是MetaCache

至于MetaCache具体的结构本文暂不关心

结论:

可以看到客户端的逻辑是,当客户端没有缓存的时候(第一次请求),会加载region 的location信息到客户端,后面直接使用cache中的信息,如果出现重试,则会重新获取location信息,更新客户端的cache。

发布了52 篇原创文章 · 获赞 4 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/Gloria_y/article/details/83755460