微信公众号：大数据开发运维架构
关注可了解更多大数据相关的资讯。问题或建议，请公众号留言;
文章从公众号复制过来，格式可能错乱，请关注公众号阅读原文
微信公众号：大数据开发运维架构
关注可了解更多大数据相关的资讯。问题或建议，请公众号留言;
如果您觉得“大数据开发运维架构”对你有帮助，欢迎转发朋友圈
从微信公众号拷贝过来，格式有些错乱，建议直接去公众号阅读
HBase1.x精通:详解HBase读缓存BlockCache(一、概述及策略）
概述：
缓存对于任何一个数据库都非常重要，如果有条件允许，我们更愿意把所有的数据都缓存到内存中，就不存在任何的磁盘IO，但对于大数据来说缓存所有数据几乎是不可能的，基于二八法则，我们80%的业务请求都集中在20%的数据里面，如果把这20%的数据缓存到内存中，数据库的性能将会有极大的提升。
HBase上Regionserver的内存分为两个部分：一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。
1).写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满128MB以后，此时当前的HRegion中所有的MemStore会Flush到HDFS中。
当一个HRegion中的所有MemStore的大小总和超过了hbase.regionserver.global.memstore.upperLimit的大小，默认40％的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush顺序是MemStore大小的倒序，直到总体的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit，默认38%的内存使用量。
2).读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。
一个Regionserver上有一个BlockCache和N个Memstore，它们的大小之和不能大于等于heapsize * 0.8，否则HBase不能正常启动。
BlockCache机制
为了高效获取数据，HBase设置了BlockCache机制，内存中缓存block，Block大体来分为两类，一类是JVM的heap内存，一类是heap off内存；第一类的cache策略叫做LRUCache，第二类Cache策略有SlabCache以及BucketCache两类；
BlockCache是Region Server级别的，一个Region Server只有一个Block Cache，在Region Server启动的时候完成Block Cache的初始化工作。到目前为止，HBase先后实现了3种Block Cache方案，LRUBlockCache是最初的实现方案，也是默认的实现方案；HBase 0.92版本实现了第二种方案SlabCache，见HBASE-4027；HBase 0.96之后官方提供了另一种可选方案BucketCache，见HBASE-7404。
BlockCache在HBase中所处的位置如下图中所示:
三种策略：
1).LRUBlockCache
Least-Recently-Used,HBase默认的BlockCache实现方案，LRU缓存把最近最少使用的数据移除，让给最新读取的数据。而往往最常读取的，也是读取次数最多的，所以，利用LRU缓存，我们能够提高系统的性能。
LRUBlockCache将缓存分为三块：single-access区、mutil-access区、in-memory区，分别占到整个BlockCache大小的25%、50%、25%。
single-access 优先级：当一个数据块第一次从HDFS读取时，它会具有这种优先级，并且在缓存空间需要被回收（置换）时，它属于优先被考虑范围内。它的优点在于：一般被扫描（scanned）读取的数据块，相较于之后会被用到的数据块，更应该被优先清除
mutil-access优先级：如果一个数据块，属于Single Access优先级，但是之后被再次访问，则它会升级为Multi Access优先级。在缓存里的内容需要被清除（置换）时，这部分内容属于次要被考虑的范围
in-memory-access优先级：表示数据可以常驻内存，一般用来存放访问频繁、数据量小的数据，比如元数据，用户也可以在建表的时候通过设置列族属性IN-MEMORY= true将此列族放入in-memory区，两种具体实现方式如下：
a.在Java中可以调用: HColumnDescriptor.setInMemory(true);
b.在hbase shell 中创建或修改一个表时，可以使用 IN_MEMORY => true，例如：create ‘t’, {NANME => ‘f’, IN_MEMORY => ‘true’}
弊端：使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多，从而可能引发臭名昭著的Full GC，触发可怕的’stop-the-world’暂停;尤其在大内存条件下，一次Full GC很可能会持续较长时间，甚至达到分钟级别。大家知道Full GC是会将整个进程暂停的（称为stop-the-wold暂停），因此长时间Full GC必然会极大影响业务的正常读写请求。
2).SlabCache
在1.0版本后被废弃了(HBASE-11307)；内部结构是划分为两块，80%和20%；缓存的数据如小于等于blocksize，则放在在前面的区域（80%区域）；如果block大于1x但是小于2x将会放置到后面区域（20%区域）；如果大于2x则不进行缓存。
和LRUBlockCache相同，SlabCache也使用Least-Recently-Used算法对过期Block进行淘汰。
和LRUBlockCache不同的是，SlabCache淘汰Block的时候只需要将对应的bufferbyte标记为空闲，后续cache对其上的内存直接进行覆盖即可。
线上集群环境中，不同表不同列族设置的BlockSize都可能不同，很显然，默认只能存储两种固定大小Block的SlabCache方案不能满足部分用户场景，比如用户设置BlockSize = 256K，简单使用SlabCache方案就不能达到这部分Block缓存的目的。因此HBase实际实现中将SlabCache和LRUBlockCache搭配使用，称为DoubleBlockCache。一次随机读中，一个Block块从HDFS中加载出来之后会在两个Cache中分别存储一份；缓存读时首先在LRUBlockCache中查找，如果Cache Miss再在SlabCache中查找，此时如果命中再将该Block放入LRUBlockCache中。
弊端：经过实际测试，DoubleBlockCache方案有很多弊端。比如SlabCache设计中固定大小内存设置会导致实际内存使用率比较低，而且使用LRUBlockCache缓存Block依然会因为JVM GC产生大量内存碎片。因此在HBase 0.98版本之后，该方案已经被不建议使用。
3).BucketCache
这种策略是阿里设计出来的 CDH集群用的这种策略，BucketCache通过配置可以工作在三种模式下：heap，offheap和file。无论工作在那种模式下，BucketCache都会申请许多带有固定大小标签的Bucket，和SlabCache一样，一种Bucket存储一种指定BlockSize的数据块，但和SlabCache不同的是，BucketCache会在初始化的时候申请14个不同大小的Bucket，而且即使在某一种Bucket空间不足的情况下，系统也会从其他Bucket空间借用内存使用，不会出现内存使用率低的情况。接下来再来看看不同工作模式，heap模式表示这些Bucket是从JVM Heap中申请，offheap模式使用DirectByteBuffer技术实现堆外内存存储管理，而file模式使用类似SSD的高速缓存文件存储数据块。
弊端：实际实现中，HBase将BucketCache和LRUBlockCache搭配使用，称为CombinedBlockCache。和DoubleBlockCache不同，系统在LRUBlockCache中主要存储Index Block和Bloom Block，而将Data Block存储在BucketCache中。因此一次随机读需要首先在LRUBlockCache中查到对应的Index Block，然后再到BucketCache查找对应数据块。BucketCache通过更加合理的设计修正了SlabCache的弊端，极大降低了JVM GC对业务请求的实际影响，但也存在一些问题，比如使用堆外内存会存在拷贝内存的问题，一定程度上会影响读写性能。当然，在后来的版本中这个问题也得到了解决，见HBASE-11425。
