背景
第一次请求某个表的时候,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。