BlockCache用来做读缓存，在每个RegionServer上只有一个BlockCache。BlockCache的默认值为0.4，它表示可用堆的40％。HBase提供了两种不同的BlockCache实现来缓存从HDFS读取的数据：默认的堆上LruBlockCache和通常是堆外的BucketCache。
默认情况下，所有用户表都启用块缓存，这意味着任何读取操作都将加载LRU缓存。 这对于许多用例而言可能是好的，但是通常需要进行进一步的调整才能获得更好的性能。 一个重要的概念是工作集大小或WSS，即：“计算任务所需的内存量”。
BlockCache的分配
- 一台将堆大小设置为1 GB并且默认块高速缓存大小的区域服务器将具有405 MB的块高速缓存可用。
- 20个区域服务器（堆大小设置为8 GB）和默认块高速缓存大小将具有63.3的块高速缓存。
- 堆大小设置为24 GB，块缓存大小为0.5的100个区域服务器将具有约1.16 TB的块缓存。
LruBlockCache
使用Java实现，并且完全在Java堆中。LruBlockCache的实现原理可以参照Java并发包的ConcurrentHashMap，管理BlockKey到Block的映射关系。LruBlockCache遵循LRU的淘汰策略。
LRUBlockCache提供了三中缓存策略。
- 单一访问优先级：占读缓存的25%，首次从HDFS加载块时，数据将被存在这块区域，它属于三种策略中优先级最低的。
多路访问优先级：占读缓存的50%，如果再次访问先前优先级组中的块，则它将升级到该区域。
内存中访问优先级：占读缓存的25%，如果该块的系列被配置为“内存中”，则无论其访问次数如何，它都将存储在此块区域，一般用来存储元数据信息和量小的数据。
标记一个列簇为内存中访问优先级
HColumnDescriptor.setInMemory(true);
LRUBlockCache缺点是当在缓存中的数据过长时间后，会被Java虚拟机从年轻代晋升到老年代，如果选择是CMS虚拟机，将造成FullGC STW（stop-the-world）。
BucketCache
BucketCache也叫做Off-heap Block Cache，BucketCache属于堆外缓存，它没有使用JVM内存管理算法来管理缓存，而是自己对内存进行管理，以此来避免出现FullGC的问题，因为BucketCache设计较为复杂，这里不再展开说明，具体细节参照官方文档。
一般来说HBase将BucketCache和LRUBlockCache搭配使用，称为CombinedBlock-Cache。和DoubleBlockCache不同，系统在LRUBlockCache中主要存储Index Block和Bloom Block，而将Data Block存储在BucketCache中。因此一次随机读需要先在LRUBlockCache中查到对应的Index Block，然后再到BucketCache查找对应Data Block。
压缩BlockCache
HBASE-11331引入了惰性BlockCache解压缩，简称为compressed BlockCache。 启用压缩的BlockCache后，数据和编码的数据块将以其磁盘上的格式缓存在BlockCache中，而不是在缓存之前进行解压缩和解密。
对于承载超出缓存容量的更多数据的RegionServer，已证明通过SNAPPY压缩启用此功能可将吞吐量提高50％，平均延迟提高30％，同时将垃圾收集增加80％，并将总CPU负载增加2％。 有关如何衡量和实现性能的更多详细信息，请参见HBASE-11331。 如果BlockCache内存比较充足或者当前的数据任务对于CPU和垃圾负载是相当敏感的，压缩BlockCache可能并不是很适合。
默认情况下，压缩的BlockCache是禁用的。 要启用它，在所有RegionServer上的hbase-site.xml中将hbase.block.data.cachecompressed设置为true。
