背景：
1、緩存對于數(shù)據(jù)庫來說極其的重要
2、最理想的情況是，所有數(shù)據(jù)都能夠緩存到內(nèi)存，這樣就不會有任何文件IO請求，讀寫性能必然會提升到極致。
3、我們并不需要將所有數(shù)據(jù)都緩存起來，根據(jù)二八法則，80%的業(yè)務(wù)請求都集中在20%的熱點數(shù)據(jù)上，
4、把20%的數(shù)據(jù)緩存起來，將這部分?jǐn)?shù)據(jù)緩存起就可以極大地提升系統(tǒng)性能。

成都創(chuàng)新互聯(lián)公司"三網(wǎng)合一"的企業(yè)建站思路。企業(yè)可建設(shè)擁有電腦版、微信版、手機版的企業(yè)網(wǎng)站。實現(xiàn)跨屏營銷，產(chǎn)品發(fā)布一步更新，電腦網(wǎng)絡(luò)+移動網(wǎng)絡(luò)一網(wǎng)打盡，滿足企業(yè)的營銷需求！成都創(chuàng)新互聯(lián)公司具備承接各種類型的成都網(wǎng)站設(shè)計、成都網(wǎng)站制作項目的能力。經(jīng)過十年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質(zhì)的服務(wù)，并獲得了客戶的一致好評。

HBase在實現(xiàn)中提供了兩種緩存結(jié)構(gòu)：MemStore和BlockCache。
MemStore
1、其中MemStore稱為寫緩存
2、HBase執(zhí)行寫操作首先會將數(shù)據(jù)寫入MemStore，并順序?qū)懭際Log，
//代碼中這樣，我們的理解為 先順序?qū)懭際Log 再將數(shù)據(jù)寫入MemStore
3、等滿足一定條件后統(tǒng)一將MemStore中數(shù)據(jù)刷新到磁盤，這種設(shè)計可以極大地提升HBase的寫性能。
4、MemStore對于讀性能也至關(guān)重要，假如沒有MemStore，讀取剛寫入的數(shù)據(jù)就需要從文件中通過IO查找，這種代價顯然是昂貴的！

BlockCache
1、BlockCache稱為讀緩存
2、HBase會將一次文件查找的Block塊緩存到Cache中，以便后續(xù)同一請求或者鄰近數(shù)據(jù)查找請求，可以直接從內(nèi)存中獲取，避免昂貴的IO操作。

簡單地回顧一下HBase中Block的概念
1、Block是HBase中最小的數(shù)據(jù)存儲單元，默認(rèn)為64K，在建表語句中可以通過參數(shù)BlockSize指定。
2、HBase中Block分為四種類型：Data Block，Index Block，Bloom Block和Meta Block。
3、其中Data Block用于存儲實際數(shù)據(jù)，通常情況下每個Data Block可以存放多條KeyValue數(shù)據(jù)對；
4、Index Block和Bloom Block都用于優(yōu)化隨機讀的查找路徑，
5、其中Index Block通過存儲索引數(shù)據(jù)加快數(shù)據(jù)查找，
6、而Bloom Block通過一定算法可以過濾掉部分一定不存在待查KeyValue的數(shù)據(jù)文件，減少不必要的IO操作；
7、Meta Block主要存儲整個HFile的元數(shù)據(jù)。

1、BlockCache是Region Server級別的，
2、一個Region Server只有一個Block Cache，在Region Server啟動的時候完成Block Cache的初始化工作。
3、到目前為止，HBase先后實現(xiàn)了3種Block Cache方案，LRUBlockCache是最初的實現(xiàn)方案，也是默認(rèn)的實現(xiàn)方案；HBase 0.92版本實現(xiàn)了第二種方案SlabCache，見HBASE-4027；HBase 0.96之后官方提供了另一種可選方案BucketCache，見HBASE-7404。
4、這三種方案的不同之處在于對內(nèi)存的管理模式，
5、其中LRUBlockCache是將所有數(shù)據(jù)都放入JVM Heap中，交給JVM進(jìn)行管理。
6、SlabCache BucketCache 這兩種采用了不同機制將部分?jǐn)?shù)據(jù)存儲在堆外，交給HBase自己管理。
7、這種演變過程是因為LRUBlockCache方案中JVM垃圾回收機制經(jīng)常會導(dǎo)致程序長時間暫停，而采用堆外內(nèi)存對數(shù)據(jù)進(jìn)行管理可以有效避免這種情況發(fā)生。

---

LRUBlockCache //HBase默認(rèn)的BlockCache實現(xiàn)方案
1、將內(nèi)存從邏輯上分為了三塊：single-access區(qū)、mutil-access區(qū)、in-memory區(qū)，分別占到整個BlockCache大小的25%、50%、25%
2、一次隨機讀中，一個Block塊從HDFS中加載出來之后首先放入signle區(qū)，
3、后續(xù)如果有多次請求訪問到這塊數(shù)據(jù)的話，就會將這塊數(shù)據(jù)移到mutil-access區(qū)。
3、而in-memory區(qū)表示數(shù)據(jù)可以常駐內(nèi)存，一般用來存放訪問頻繁、數(shù)據(jù)量小的數(shù)據(jù)，比如元數(shù)據(jù)，用戶也可以在建表的時候通過設(shè)置列族屬性IN-MEMORY= true將此列族放入in-memory區(qū)。 //這一部分參考 HBase － 建表語句解析 http://hbasefly.com/2016/03/23/hbase_create_table/ 中提到的 IN_MEMORY 參數(shù)
4、很顯然，這種設(shè)計策略類似于JVM中young區(qū)、old區(qū)以及perm區(qū)。
階段小結(jié)：
LRUBlockCache機制：類似于jvm的young區(qū)、old區(qū)以及perm區(qū)，他分為（single-access區(qū)、mutil-access區(qū)、in-memory區(qū)，分別占到整個BlockCache大小的25%、50%、25%）在一次隨機訪問數(shù)據(jù)的時候從hdfs加載出來，放到single-access區(qū)，后續(xù)如果有多次請求這塊的數(shù)據(jù)，就會放到 mutil-access區(qū) 而in-memory區(qū)表示數(shù)據(jù)可以常駐內(nèi)存，一般用來存放訪問頻繁、數(shù)據(jù)量小的數(shù)據(jù)，比如元數(shù)據(jù)。
//當(dāng)BlockCache總量達(dá)到一定閾值之后就會啟動淘汰機制，最少使用的Block會被置換出來，為新加載的Block預(yù)留空間。
缺點：使用LRUBlockCache緩存機制會因為CMS GC策略導(dǎo)致內(nèi)存碎片過多，從而可能引發(fā)臭名昭著的Full GC，觸發(fā)可怕的’stop-the-world’暫停，嚴(yán)重影響上層業(yè)務(wù)
那CMS GC策略如何導(dǎo)致內(nèi)存碎片過多？內(nèi)存碎片過多如何觸發(fā)Full GC？請關(guān)注博主另一篇博客。

SlabCache //已經(jīng)被淘汰了
1、為了解決LRUBlockCache方案中因為JVM垃圾回收導(dǎo)致的服務(wù)中斷，SlabCache方案使用Java NIO DirectByteBuffer技術(shù)實現(xiàn)了堆外內(nèi)存存儲，不再由JVM管理數(shù)據(jù)內(nèi)存。
2、默認(rèn)情況下，系統(tǒng)在初始化的時候會分配兩個緩存區(qū)，分別占整個BlockCache大小的80%和20%，每個緩存區(qū)分別存儲固定大小的Block塊，
3、其中前者主要存儲小于等于64K大小的Block，后者存儲小于等于128K Block，如果一個Block太大就會導(dǎo)致兩個區(qū)都無法緩存。
4、和LRUBlockCache相同，SlabCache也使用Least-Recently-Used算法對過期Block進(jìn)行淘汰。
5、和LRUBlockCache不同的是，SlabCache淘汰Block的時候只需要將對應(yīng)的bufferbyte標(biāo)記為空閑，后續(xù)cache對其上的內(nèi)存直接進(jìn)行覆蓋即可。

SlabCache 和 DoubleBlockCache 缺點為：
線上集群環(huán)境中，不同表不同列族設(shè)置的BlockSize都可能不同，很顯然，默認(rèn)只能存儲兩種固定大小Block的SlabCache方案不能滿足部分用戶場景，
因此HBase實際實現(xiàn)中將SlabCache和LRUBlockCache搭配使用，稱為DoubleBlockCache。
1、DoubleBlockCache方案有很多弊端。比如SlabCache設(shè)計中固定大小內(nèi)存設(shè)置會導(dǎo)致實際內(nèi)存使用率比較低，
2、而且使用LRUBlockCache緩存Block依然會因為JVM GC產(chǎn)生大量內(nèi)存碎片。
3、因此在HBase 0.98版本之后，該方案已經(jīng)被不建議使用。
階段小結(jié)：
SlabCache:實現(xiàn)的是堆外內(nèi)存存儲，不在由JVM管理數(shù)據(jù)內(nèi)存。
DoubleBlockCache：因此HBase實際實現(xiàn)中將SlabCache和LRUBlockCache搭配使用，稱DoubleBlockCache。
為什么要搭配使用呢？或者說是SlabCache的缺點
1、線上集群環(huán)境中，不同表不同列族設(shè)置的BlockSize都可能不同，很顯然，默認(rèn)只能存儲兩種固定大小Block的SlabCache方案不能滿足部分用戶場景，比如用戶設(shè)置BlockSize = 256K，簡單使用SlabCache方案就不能達(dá)到這部分Block緩存的目的。
2、一次隨機讀中，一個Block塊從HDFS中加載出來之后會在兩個Cache中分別存儲一份；緩存讀時首先在LRUBlockCache中查找，如果Cache Miss再在SlabCache中查找，此時如果命中再將該Block放入LRUBlockCache中。
缺點：
DoubleBlockCache方案有很多弊端。比如SlabCache設(shè)計中固定大小內(nèi)存設(shè)置會導(dǎo)致實際內(nèi)存使用率比較低，而且使用LRUBlockCache緩存Block依然會因為JVM GC產(chǎn)生大量內(nèi)存碎片。因此在HBase 0.98版本之后，該方案已經(jīng)被不建議使用。
//已經(jīng)淘汰了

BucketCache //阿里設(shè)計出來的 cdh用的這種 //可以參考：hbase針對fullgc所做的優(yōu)化（Memstore所作的優(yōu)化 針對BlockCache所作優(yōu)化）：https://blog.51cto.com/12445535/2373223
1、SlabCache方案在實際應(yīng)用中并沒有很大程度改善原有LRUBlockCache方案的GC弊端，還額外引入了諸如堆外內(nèi)存使用率低的缺陷。然而它的設(shè)計并不是一無是處，至少在使用堆外內(nèi)存這個方面給予了阿里大牛們很多啟發(fā)。站在SlabCache的肩膀上，他們開發(fā)了BucketCache緩存方案并貢獻(xiàn)給了社區(qū)。
2、實際實現(xiàn)中，HBase將BucketCache和LRUBlockCache搭配使用，稱為CombinedBlockCache。
3、和DoubleBlockCache不同，系統(tǒng)在LRUBlockCache中主要存儲Index Block和Bloom Block，而將Data Block存儲在BucketCache中
4、因此一次隨機讀需要首先在LRUBlockCache中查到對應(yīng)的Index Block，然后再到BucketCache查找對應(yīng)數(shù)據(jù)塊。BucketCache通過更加合理的設(shè)計修正了SlabCache的弊端，極大降低了JVM GC對業(yè)務(wù)請求的實際影響，
5、但也存在一些問題，比如使用堆外內(nèi)存會存在拷貝內(nèi)存的問題，一定程度上會影響讀寫性能。當(dāng)然，在后來的版本中這個問題也得到了解決，
優(yōu)點：
而Bucket Cache緩存機制因為在初始化的時候就申請了一片固定大小的內(nèi)存作為緩存，緩存淘汰不再由 JVM管理，數(shù)據(jù)Block的緩存操作只是對這片空間的訪問和覆蓋，因而大大減少了內(nèi)存碎片的出現(xiàn)，降低了Full GC發(fā)生的頻率。//Bucket Cache 緩存淘汰不再由 JVM管理 降低了Full GC發(fā)生的頻率。
Bucket Cache 緩存 中有3中模式 heap模式和offheap模式 file模式
offheap模式因為內(nèi)存屬于操作系統(tǒng)，所以基本不會產(chǎn)生CMS GC，也就在任何情況下都不會因為內(nèi)存碎片導(dǎo)致觸發(fā)Full GC。

LRUBlockCache //升入了解
1、它使用一個ConcurrentHashMap管理BlockKey到Block的映射關(guān)系，
2、緩存Block只需要將BlockKey和對應(yīng)的Block放入該HashMap中，查詢緩存就根據(jù)BlockKey從HashMap中獲取即可。
3、同時該方案采用嚴(yán)格的LRU淘汰算法，當(dāng)Block Cache總量達(dá)到一定閾值之后就會啟動淘汰機制，最近最少使用的Block會被置換出來。在具體的實現(xiàn)細(xì)節(jié)方面，需要關(guān)注三點：

1. 緩存分層策略
   //將整個BlockCache分為三個部分：single-access、mutil-access和inMemory。需要特別注意的是，HBase系統(tǒng)元數(shù)據(jù)存放在InMemory區(qū)，因此設(shè)置數(shù)據(jù)屬性InMemory = true需要非常謹(jǐn)慎，確保此列族數(shù)據(jù)量很小且訪問頻繁，否則有可能會將hbase.meta元數(shù)據(jù)擠出內(nèi)存，嚴(yán)重影響所有業(yè)務(wù)性能。

2. LRU淘汰算法實現(xiàn)

3. LRU方案優(yōu)缺點
   //LRU方案使用JVM提供的HashMap管理緩存，簡單有效。
   但是：會出現(xiàn)full gc 碎片空間一直累計就會產(chǎn)生臭名昭著的Full GC。
   尤其在大內(nèi)存條件下，一次Full GC很可能會持續(xù)較長時間，甚至達(dá)到分鐘級別。大家知道Full GC是會將整個進(jìn)程暫停的（稱為stop-the-wold暫停），因此長時間Full GC必然會極大影響業(yè)務(wù)的正常讀寫請求。

BucketCache //升入了解概念 見博客 cdh默認(rèn)是這種緩存模式
//它沒有使用JVM 內(nèi)存管理算法來管理緩存，而是自己對內(nèi)存進(jìn)行管理，因此不會因為出現(xiàn)大量碎片導(dǎo)致Full GC的情況發(fā)生。

內(nèi)存組織形式

Block緩存寫入、讀取流程

BucketCache工作模式

BucketCache配置使用 //重點 //cdh用的這種模式
//
BucketCache 的總大小，以 MB 為單位。要配置的大小取決于可供 HBase 使用的內(nèi)存量或本地 SSD 的大小。如果將 hbase.bucketcache.ioengine 設(shè)為“offheap”，則 BucketCache 會消耗 Java 的直接內(nèi)存中的已配置內(nèi)存量。
hbase.bucketcache.size = 1M

提示：
其中heap模式和offheap模式都使用內(nèi)存作為最終存儲介質(zhì)，內(nèi)存分配查詢也都使用Java NIO ByteBuffer技術(shù)，不同的是，heap模式分配內(nèi)存會調(diào)用byteBuffer.allocate方法，從JVM提供的heap區(qū)分配，而后者會調(diào)用byteBuffer.allocateDirect方法，直接從操作系統(tǒng)分配。
這兩種內(nèi)存分配模式會對HBase實際工作性能產(chǎn)生一定的影響。影響最大的無疑是GC ，相比heap模式，offheap模式因為內(nèi)存屬于操作系統(tǒng)，所以基本不會產(chǎn)生CMS GC，也就在任何情況下都不會因為內(nèi)存碎片導(dǎo)致觸發(fā)Full GC。
除此之外，在內(nèi)存分配以及讀取方面，兩者性能也有不同，比如，內(nèi)存分配時heap模式需要首先從操作系統(tǒng)分配內(nèi)存再拷貝到JVM heap，相比offheap直接從操作系統(tǒng)分配內(nèi)存更耗時；但是反過來，讀取緩存時heap模式可以從JVM heap中直接讀取，而offheap模式則需要首先從操作系統(tǒng)拷貝到JVM heap再讀取，顯得后者更費時。

file模式和前面兩者不同，它使用Fussion-IO或者SSD等作為存儲介質(zhì)，相比昂貴的內(nèi)存，這樣可以提供更大的存儲容量，因此可以極大地提升緩存命中率。

提示：
LRUBlockCache
SlabCache
DoubleBlockCache：因此HBase實際實現(xiàn)中將SlabCache和LRUBlockCache搭配使用，稱為DoubleBlockCache //淘汰了
BucketCache //推薦用的 堆外內(nèi)存機制 cdh用的這個
CombinedBlockCache：HBase將BucketCache和LRUBlockCache搭配使用，稱為CombinedBlockCache。

總結(jié)：
所以經(jīng)過上面的分析之后，最后剩下LRU君（LRUBlockCache）和CBC君（CombinedBlockCache）。
我們具體分析：
結(jié)論
看完了所有比較重要的指標(biāo)對比數(shù)據(jù)，我們可以得出以下兩點：

1. 在’緩存全部命中’場景下，LRU君可謂完勝CBC君。因此如果總數(shù)據(jù)量相比JVM內(nèi)存容量很小的時候，選擇LRU君；
2. 在所有其他存在緩存未命中情況的場景下， LRU君的GC性能幾乎只有CBC君的1/3，而吞吐量、讀寫延遲、IO、CPU等指標(biāo)兩者基本相當(dāng)，因此建議選擇CBC。
   理論解釋
   1、之所以在’緩存全部命中’場景下LRU的各項指標(biāo)完勝CBC，
   2、而在’緩存大量未命中’的場景下，LRU各項指標(biāo)與CBC基本相當(dāng)，
   3、是因為HBase在讀取數(shù)據(jù)的時候，如果都緩存命中的話，對于CBC，需要將堆外內(nèi)存先拷貝到JVM內(nèi)，然后再返回給用戶，流程比LRU君的堆內(nèi)內(nèi)存復(fù)雜，延遲就會更高。
   4、而如果大量緩存未命中，內(nèi)存操作就會占比很小，延遲瓶頸主要在于IO，使得LRU和CBC兩者各項指標(biāo)基本相當(dāng)。

參考鏈接：
HBase BlockCache系列 – 走進(jìn)BlockCache http://hbasefly.com/2016/04/08/hbase-blockcache-1/
HBase BlockCache系列 － 探求BlockCache實現(xiàn)機制 http://hbasefly.com/2016/04/26/hbase-blockcache-2/
HBase BlockCache系列 － 性能對比測試報告 http://hbasefly.com/2016/05/06/hbase-blockcache-3/

本文名稱：hbase中兩種緩存機制memstore和blockcache詳解（必看）
本文路徑：http://aaarwkj.com/article6/godiog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、手機網(wǎng)站建設(shè)、服務(wù)器托管、搜索引擎優(yōu)化、網(wǎng)頁設(shè)計公司、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)