Blockcache主要是为了提高对storefile的访问效率而增加的内存结构，通过将常访问的数据缓存在内存中来实现。
其实hbase中除了常常介绍的lrublockcache以外，还有一种是slabcache。
先简单的说明下slabcache。如果对oracle的cache管理比较熟悉的话就很容易理解slabcache，他们的基本原理是相同的。将cache根据不同的slabsize分成若干小的cache，当block数据cache到slabcache中的时候，首先要计算该block的大小，如果该block太大，找不到合适的slab则不进行缓存，直接丢弃。如果找到合适的slab，那么就将该数据存储在相应的slab中。在插入的过程中通过大小来判断，而在对slabsize则利用另外的索引结构，通过BlockCacheKey结构来查询，该结构由hfileName和offset组成。slabcache结构不是使用的lru算法进行数据的淘汰，而是简单的先进先出队列。可以想象，slabcache的结构比较简单，存储效率高，但是淘汰算法比较差。
插一句，默认情况下，hbase选择的是lrublockcache，而当我们设置了hbase.offheapcache.percentage等参数后，会启用DoubleBlockCache，实际上就是lrublockcache和slabcache的混合。
在说平时最常使用lrublockcache。根据最近使用的情况来进行淘汰，经常使用的会被保留，而不经常使用会被淘汰。hbase中的lrublockcache分成三个层次：memory,single,multi。
memory级别不会受到其他两个级别的影响，只有那些指定blockcache为memory的表的数据才会设置成memory，系统表.META.和-ROOT-默认的会被指定为memory。
single级别是那些第一被访问并放在在blockcache中的数据的级别，而当single中的数据第二次被访问后级别会升到multi级别。这样可以很好的防止单次大数据量访问对blockcache的清洗，至于multi级别的数据可以免于被清洗掉。
默认情况下，三者的分配比例为，memory为25%，single为25%，multi为50%。
淘汰数据的进程会一直的运行，找到那些需要被淘汰的数据。该进程分别统计各个级别的数据，如果总量超过DEFAULT_ACCEPTABLE_FACTOR（0.85）的限制，就会被强制的进行淘汰，直到到达安全线以下，该安全线应该是DEFAULT_MIN_FACTOR（0.75）指定的。