白话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。