怎么理解HBase1.x讀緩存BlockCache

1.概述

緩存對于任何一個數據庫都非常重要，如果有條件允許，我們更愿意把所有的數據都緩存到內存中，就不存在任何的磁盤IO，但對于大數據來說緩存所有數據幾乎是不可能的，基于二八法則，我們80%的業(yè)務請求都集中在20%的數據里面，如果把這20%的數據緩存到內存中，數據庫的性能將會有極大的提升。

HBase上Regionserver的內存分為兩個部分：一部分作為Memstore，主要用來寫；另外一部分作為BlockCache，主要用于讀。

1）寫請求會先寫入Memstore，Regionserver會給每個HStore提供一個Memstore，當Memstore滿128MB以后，此時當前的HRegion中所有的MemStore會Flush到HDFS中。

當一個regionserver中的所有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不能正常啟動。

2.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區(qū)、mutil-access區(qū)、in-memory區(qū)，分別占到整個BlockCache大小的25%、50%、25%。

• single-access 優(yōu)先級：當一個數據塊第一次從HDFS讀取時，它會具有這種優(yōu)先級，并且在緩存空間需要被回收（置換）時，它屬于優(yōu)先被考慮范圍內。它的優(yōu)點在于：一般被掃描（scanned）讀取的數據塊，相較于之后會被用到的數據塊，更應該被優(yōu)先清除

• mutil-access優(yōu)先級：如果一個數據塊，屬于Single Access優(yōu)先級，但是之后被再次訪問，則它會升級為Multi Access優(yōu)先級。在緩存里的內容需要被清除（置換）時，這部分內容屬于次要被考慮的范圍

• in-memory-access優(yōu)先級：表示數據可以常駐內存，一般用來存放訪問頻繁、數據量小的數據，比如元數據，用戶也可以在建表的時候通過設置列族屬性IN-MEMORY= true將此列族放入in-memory區(qū)，兩種具體實現方式如下：

a.在Java中可以調用: HColumnDescriptor.setInMemory(true);

b.在hbase shell 中創(chuàng)建或修改一個表時，可以使用 IN_MEMORY => true，例如：create ‘t’, {NANME => ‘f’, IN_MEMORY => ‘true’}

弊端：使用LRUBlockCache緩存機制會因為CMS GC策略導致內存碎片過多，從而可能引發(fā)臭名昭著的Full GC，觸發(fā)可怕的’stop-the-world’暫停;尤其在大內存條件下，一次Full GC很可能會持續(xù)較長時間，甚至達到分鐘級別。大家知道Full GC是會將整個進程暫停的（稱為stop-the-wold暫停），因此長時間Full GC必然會極大影響業(yè)務的正常讀寫請求。

2. SlabCache

在1.0版本后被廢棄了(HBASE-11307)；內部結構是劃分為兩塊，80%和20%；緩存的數據如小于等于blocksize，則放在在前面的區(qū)域（80%區(qū)域）；如果block大于1x但是小于2x將會放置到后面區(qū)域（20%區(qū)域）；如果大于2x則不進行緩存。

和LRUBlockCache相同，SlabCache也使用Least-Recently-Used算法對過期Block進行淘汰。

和LRUBlockCache不同的是，SlabCache淘汰Block的時候只需要將對應的bufferbyte標記為空閑，后續(xù)cache對其上的內存直接進行覆蓋即可。

線上集群環(huán)境中，不同表不同列族設置的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對業(yè)務請求的實際影響，但也存在一些問題，比如使用堆外內存會存在拷貝內存的問題，一定程度上會影響讀寫性能。