HBase Block Cache的重要实现细节和In-Memory Cache的特点

注：本文基于HBase 0.94.1的源码进行分析。本文原文连接： http://blog.csdn.net/bluishglc/article/details/21516067，转载请著明出处！

每load一个block到cache时，都会检查当前cache的size是否已经超过了“警戒线”，这个“警戒线”是一个规定的当前block cache总体积占额定体积的安全比例，默认该值是0.85，即当加载了一个block到cache后总大小超过了既定的85%就开始触发异步的evict操作了。

evict的逻辑是这样的：遍历cache中的所有block,根据它们所属的级别(single,multi,in-memory)分拨到三个优先级队列中，队头元素是最旧（最近访问日间值最小）的那个block。对这个三队列依次驱逐对头元素，释放空间。

所以说:in-memory的block与其他类型的block并无本质上的不同，它不会长久驻留cache而不被逐出cache, 当不断有新的in-memory的block被访问，而现有in-memory cache已达到上限时，旧的in-memory block就会被替换出去，除非，所有in-memory的block的总体积小于in-memory cache。

但是in-memory的block确实不同于其他两种block的地方在于它的这个“in-memory”特征是静态指定的（在column family上设置），不会像其他两种cache会因访问频率而发生改变，这就决定了它的独立性，另外两种block访问次数再多也不会被放到in-memory的区段里去，in-memory的block不管是第几次访问，总是被放置到in-memory的区段中。

从in-memory cache的这些特性上来看，需要特别强调的是：

1. 标记IN_MEMORY=>'true'的column family的总体积最好不要超过in-memory cache的大小（in-memory cache = heap size * hfile.block.cache.size * 0.85 * 0.25），特别是当总体积远远大于了in-memory cache时，会在in-memory cache上发生严重的颠簸。

2. 换个角度再看，普遍提到的使用in-memory cache的场景是把元数据表的column family声明为IN_MEMORY=>'true。实际上这里的潜台词是：元数据表都很小。其时我们也可以大胆地把一些需要经常访问的，总体积不会超过in-memory cache的column family都设为IN_MEMORY=>'true'从而更加充分地利用cache空间。就像前面提到的，普通的block永远是不会被放入in-memory cache的，只存放少量metadata是对in-memory cache资源的浪费（未来的版本应该提供三种区段的比例配置功能）。