HBase Block Cache的重要实现细节和In-Memory Cache的特点-优快云博客

每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资源的浪费（未来的版本应该提供三种区段的比例配置功能）。

1.2 Row Key

HBase中row key用来检索表中的记录，支持以下三种方式：

通过单个row key访问：即按照某个row key键值进行get操作；
通过row key的range进行scan：即通过设置startRowKey和endRowKey，在这个范围内进行扫描；
全表扫描：即直接扫描整张表中所有行记录。

在HBase中，row key可以是任意字符串，最大长度64KB，实际应用中一般为10~100bytes，存为byte[]字节数组，一般设计成定长的。

row key是按照字典序存储，因此，设计row key时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。

举个例子：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为row key的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE – timestamp作为row key，这样能保证新写入的数据在读取时可以被快速命中。

1.3 Column Family

不要在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O。感兴趣的同学可以对自己的HBase集群进行实际测试，从得到的测试结果数据验证一下。