HBase深入分析之RegionServer
所有的用戶數(shù)據(jù)以及元數(shù)據(jù)的請求，在經(jīng)過Region的定位，最終會(huì)落在RegionServer上，并由RegionServer實(shí)現(xiàn)數(shù)據(jù)的讀寫操作。本小節(jié)將重點(diǎn)介紹RegionServer的代碼結(jié)構(gòu)和功能，從實(shí)現(xiàn)細(xì)節(jié)上深入理解RegionServer對于數(shù)據(jù)的操作流程。
1 RegionServer概述
RegionServer是HBase集群運(yùn)行在每個(gè)工作節(jié)點(diǎn)上的服務(wù)。它是整個(gè)HBase系統(tǒng)的關(guān)鍵所在，一方面它維護(hù)了Region的狀態(tài)，提供了對于Region的管理和服務(wù)；另一方面，它與Master交互，上傳Region的負(fù)載信息上傳，參與Master的分布式協(xié)調(diào)管理。具體如圖(1)所示。
HRegionServer與HMaster以及Client之間采用RPC協(xié)議進(jìn)行通信。HRegionServer向HMaster定期匯報(bào)節(jié)點(diǎn)的負(fù)載狀況，包括RS內(nèi)存使用狀態(tài)、在線狀態(tài)的Region等信息，在該過程中RS扮演了RPC客戶端的角色，而HMaster扮演了RPC服務(wù)器端的角色。RS內(nèi)置的RpcServer實(shí)現(xiàn)了數(shù)據(jù)更新、讀取、刪除的操作，以及Region涉及到Flush、Compaction、Open、Close、Load文件等功能性操作。此時(shí)，RS扮演了RPC服務(wù)的服務(wù)端的角色。RS與Client之間的RPC是HBase最為核心的操作，其服務(wù)狀況的好壞，直接反映了RS內(nèi)部、以及它所依賴的HDFS服務(wù)質(zhì)量的好壞，因此，該過程的RPC經(jīng)常成為分析讀寫性能異常的突破口。
從RegionServer實(shí)現(xiàn)的功能上而言，除了與HMaster和Client之間的RPC通信之外，還包括如下幾個(gè)重要的模塊：
（1）依托ZookeeperWatcher進(jìn)行的分布式信息共享與任務(wù)協(xié)調(diào)的工作。
MasterAddressTracker：捕獲Master服務(wù)節(jié)點(diǎn)的變化。
HBase使用多Master來解決Master單點(diǎn)故障的問題，主Master服務(wù)故障時(shí)，它與ZooKeeper的心跳延遲超過閾值，ZooKeeeper路徑下的數(shù)據(jù)被清理，備Master上的ActiveMaserManager服務(wù)會(huì)競爭該Master路徑，成為主Master。
MasterAddresTracker是RS內(nèi)部監(jiān)聽Master節(jié)點(diǎn)變化的追蹤器。
（[yù zhí]閾值，閾值又叫臨界值，是指一個(gè)效應(yīng)能夠產(chǎn)生的最低值或最高值。閾值又稱閾強(qiáng)度，是指釋放一個(gè)行為反應(yīng)所需要的最小刺激強(qiáng)度。低于閾值的刺激不能導(dǎo)致行為釋放。）
ClusterStatusTracker：HBase集群狀態(tài)追蹤器。
該選項(xiàng)可以標(biāo)識當(dāng)前集群的狀態(tài)，及它的啟動(dòng)時(shí)間。
該設(shè)置選項(xiàng)有利于集群中的各個(gè)工作節(jié)點(diǎn)(RS)統(tǒng)一執(zhí)行啟動(dòng)和退出操作。
CatalogTracker：跟蹤-ROOT-、.META.表的Region的狀態(tài)。在HBase支持的-ROOT-、.META.、以及User Region三層樹級目錄結(jié)構(gòu)中，-ROOT-、.META.表用來定位Region的位置，追蹤-ROOT-表和.META.表對應(yīng)Region的變化，可以時(shí)刻保證整個(gè)層次目錄樹的完整性。
SplitLogWorker：基于Region的HLog文件切分器。在RS宕機(jī)之后，RS上的保存的HLog文件，需要按照Region進(jìn)行切分。HMaster會(huì)把這些文件作為任務(wù)放置到Zookeeper的splitlog路徑下，RS上SplitLogWorker會(huì)嘗試獲取任務(wù)，對獲取到的HLog文件按照Region進(jìn)行分組，處理的結(jié)果保存到相應(yīng)Region的recovered.edits目錄下。
（2）Region的管理。
Region是HBase數(shù)據(jù)存儲和管理的基本單位。Client從.META.表的查找RowKey對應(yīng)的Region的位置，每個(gè)Region只能被一個(gè)RS提供服務(wù)，RS可以同時(shí)服務(wù)多個(gè)Region，來自不同RS上的Region組合成表格的整體邏輯視圖。
RS內(nèi)涉及到提供的有關(guān)Region維護(hù)的服務(wù)組件有：
1） MemStoreFlusher，控制RS的內(nèi)存使用，有選擇性地將Region的MemStore數(shù)據(jù)寫入文件。該組件可以有效地控制RS的內(nèi)存使用，flush文件的速度在一定程度上可以反應(yīng)HBase寫服務(wù)的繁忙狀況。
2） CompactSplitThread，合并文件清理不需要的數(shù)據(jù)，控制Region的規(guī)模。在Store內(nèi)的文件個(gè)數(shù)超過閾值時(shí)，觸發(fā)Compact合并文件操作，一是清理被刪除的數(shù)據(jù)，二是多余版本的清理。在Region內(nèi)的Store文件大小超過閾值，會(huì)觸發(fā)Region的Split操作，一個(gè)Region被切分成兩個(gè)Region。這兩個(gè)操作都是在CompactSplitThread的各自的線程池中被觸發(fā)。
3） CompactionChecker，周期性檢查RS上的Region是否需要進(jìn)行Compaction操作，確認(rèn)需要進(jìn)行Compaction操作的Region，提交給CompactSplitThread執(zhí)行請求。
RS的內(nèi)存的使用分為MemStore和BlockCache。其中MemStore提供寫操作的緩存，而BlockCache是提供的讀請求緩存。它們詳細(xì)的內(nèi)容會(huì)在后續(xù)章節(jié)中介紹。
（3）WAL的管理。
HBase對于數(shù)據(jù)的更新和刪除操作默認(rèn)先Append到HLog文件，然后再更新到RS對應(yīng)的Region上，因此，由HLog文件在RS的處理方式，被稱為Write-Ahead-Log。多個(gè)Region的更新刪除操作會(huì)被相繼寫入同一個(gè)文件，出于以下的原因，HLog文件會(huì)被截?cái)?，然后?chuàng)建新HLog文件繼續(xù)當(dāng)前的Append操作。
1） Append操作失敗，避免因底層文件系統(tǒng)的文件異常，阻塞數(shù)據(jù)的操作。
2） 降低存儲空間的開銷。當(dāng)HLog上記錄的數(shù)據(jù)完全從MemStore寫入HDFS，此時(shí)如果多個(gè)HLog文件，有利于篩選冗余的HLog文件，提高存儲空間的效率。
3） 提高分布式HLog文件切分操作(Distributed Log Split)的效率。多個(gè)HLog文件就對應(yīng)同樣數(shù)目的LogSplit子任務(wù)，從而可以借助多個(gè)RS的SplitLogWorker組件快速完成HLog文件的切分，盡快恢復(fù)Region的服務(wù)。
在RS內(nèi)，LogRoller定期刷新出一個(gè)新的HLog文件。
（4）Metrics
Metrics對外提供了衡量HBase內(nèi)部服務(wù)狀況的參數(shù)。RegionServer內(nèi)Metrics包含了內(nèi)存使用、Region服務(wù)狀況、Compaction、blockCache等一系列標(biāo)識服務(wù)狀況的參數(shù)。HBase Metrics繼承Hadoop Metrics的實(shí)現(xiàn)，目前支持文件、Ganglia、以及數(shù)據(jù)流等多種輸出方式，可以針對輸出的Metrics信息靈活構(gòu)建監(jiān)控系統(tǒng)。
（5）HttpServer
RS內(nèi)置了一個(gè)Jetty Web Server，用來對外提供RS的訪問頁面。訪問頁面目前支持實(shí)時(shí)Metrics信息查詢、日志查詢、線程的Dump、修改日志級別等操作。
2 RegionServer的啟動(dòng)過程分析
RegionServer服務(wù)由org.apache.hadoop.hbase.regionserver.HRegionServer類提供。該類實(shí)現(xiàn)了四個(gè)接口，分別是HRegionInterface，RegionServerServices，HBaseRPCErrorHandler和Runnable。其中，
HRegionInterface定義了RS對外提供的RPC訪問接口，通過RPCServer內(nèi)置的Handler來處理請求；
RegionServerServices定義了基于RS內(nèi)部的服務(wù)信息接口，例如onlineRegions增、刪、查接口，以及獲取HLog、文件系統(tǒng)等接口；
HBaseRPCErrorHandler定義了RPCServer異常狀態(tài)檢測處理接口；
Runnable是Java庫中的線程接口，實(shí)現(xiàn)該接口意味著RegionServer生命周期會(huì)運(yùn)行在run()的函數(shù)體內(nèi)。
RegionServer是一個(gè)獨(dú)立的服務(wù)，有一個(gè)main函數(shù)在啟動(dòng)時(shí)被調(diào)用，main函數(shù)內(nèi)通過HRegionServerCommandLine的反射機(jī)制在JVM內(nèi)動(dòng)態(tài)加載RegionServer實(shí)現(xiàn)類，并按照args解析參數(shù)情況，決定啟動(dòng)或者關(guān)閉RS服務(wù)。
publicclassHRegionServerimplementsHRegionInterface,HBaseRPCErrorHandler,Runnable,RegionServerServices{...//成員變量定義和成員函數(shù)實(shí)現(xiàn)publicstaticvoidmain(String[]args)throwsException{...Configurationconf=HBaseConfiguration.create();@SuppressWarnings("unchecked")ClassregionServerClass=(Class)conf.getClass(HConstants.REGION_SERVER_IMPL, HRegionServer.class);//獲取RegionServer對應(yīng)的類newHRegionServerCommandLine(regionServerClass).doMain(args);//創(chuàng)建RegionServer實(shí)例并啟動(dòng)}...}
初始化與執(zhí)行過程包括：
（1）構(gòu)造HRegionServer實(shí)例，初始化變量和對象。這涉及到以下重要變量初始化：
protected volatile boolean stopped = false;//關(guān)閉Server的標(biāo)識，關(guān)閉過程中會(huì)置成ture
private boolean stopping = false;//關(guān)閉Region過程的標(biāo)識，是進(jìn)入stopped之前的狀態(tài)
protected volatile boolean fsOk;//文件系統(tǒng)狀態(tài)標(biāo)識，false表示文件系統(tǒng)不可用
private final ConcurrentSkipListMap regionsInTransitionInRS =
new ConcurrentSkipListMap(Bytes.BYTES_COMPARATOR);//RS內(nèi)處于遷移過程中的Region，其中true表示在open，false表示在close
protected final Map onlineRegions =
new ConcurrentHashMap();//RS內(nèi)正在服務(wù)的Region
protected final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();//修改onlineRegions對象的讀寫鎖
protected final int threadWakeFrequency;//工作線程服務(wù)周期間隔
private final int msgInterval;//向Master匯報(bào)心跳，收集Metrics間隔
private final long maxScannerResultSize;//Scanner執(zhí)行next返回的數(shù)據(jù)量閾值，默認(rèn)設(shè)置是Long.MAX_VALUE
private int webuiport = -1;//webServer的端口號
private final long startcode;//HRegiongServer初始化的時(shí)間，取自系統(tǒng)時(shí)間
private ServerName serverNameFromMasterPOV;//標(biāo)識Server的名字
private final int rpcTimeout;//定義到HMaster之間的rpc超時(shí)時(shí)間
在RS上重要的對象列表，如表1所示。
表1RegionServer重要對象的解釋
（2）監(jiān)聽服務(wù)組件的初始化與執(zhí)行。
這個(gè)過程初始化以ZooKeeperWatcher為基礎(chǔ)的服務(wù)，例如監(jiān)聽Master服務(wù)節(jié)點(diǎn)的MasterAddressManager，標(biāo)識HBase集群狀態(tài)的ClusterStatusTracker，以及元數(shù)據(jù)(-ROOT-, .META.)變化的監(jiān)聽器。啟動(dòng)這些服務(wù)可以保證整個(gè)集群信息協(xié)調(diào)一致。
（3）RS服務(wù)組件的初始化與執(zhí)行。
這個(gè)過程是初始化compactSplitThread，cacheFlusher，compactionChecker，以及Leases。
（4）嘗試連接HMaster，注冊RS到HMaster。
（5）周期性收集Metrics和向Master發(fā)送心跳。
3 Store相關(guān)
Region是RS上的基本數(shù)據(jù)服務(wù)單位，用戶表格由1個(gè)或者多個(gè)Region組成，根據(jù)Table的Schema定義，在Region內(nèi)每個(gè)ColumnFamily的數(shù)據(jù)組成一個(gè)Store。每個(gè)Store內(nèi)包括一個(gè)MemStore和若干個(gè)StoreFile(HFile)組成。如圖(3)所示。本小節(jié)將介紹Store內(nèi)的MemStore、StoreFile(HFile)的內(nèi)部結(jié)構(gòu)與實(shí)現(xiàn)。
3.1 MemStore原理與實(shí)現(xiàn)分析
MemStore是一個(gè)內(nèi)存區(qū)域，用以緩存Store內(nèi)最近一批數(shù)據(jù)的更新操作。對于Region指定的ColumnFamily下的更新操作(Put、Delete)，首先根據(jù)是否寫WriteAheadLog，決定是否append到HLog文件，然后更新到Store的MemStore中。顯然，MemStore的容量不會(huì)一直增長下去，因此，在每次執(zhí)行更新操作時(shí)，都會(huì)判斷RS上所有的MemStore的內(nèi)存容量是否超過閾值，如果超過閾值，通過一定的算法，選擇Region上的MemStore上的數(shù)據(jù)Flush到文件系統(tǒng)。更詳細(xì)的處理流程圖如圖(4)。
MemStore類內(nèi)的重要的成員變量：
volatileKeyValueSkipListSet kvset;//內(nèi)存中存放更新的KV的數(shù)據(jù)結(jié)構(gòu)volatileKeyValueSkipListSet snapshot;//Flush操作時(shí)的KV暫存區(qū)域finalReentrantReadWriteLock lock=newReentrantReadWriteLock();//Flush操作與kvset之間的可重入讀寫鎖finalAtomicLong size;//跟蹤記錄MemStore的占用的Heap內(nèi)存大小TimeRangeTracker timeRangeTracker;//跟蹤記錄kvset的最小和最大時(shí)間戳TimeRangeTracker snapshotTimeRangeTracker;//跟蹤記錄snapshot的最小和最大時(shí)間戳MemStoreLAB allocator;//實(shí)際內(nèi)存分配器
注意：
KeyValueSkipListSet是對于jdk提供的ConcurrentSkipListMap的封裝，Map結(jié)構(gòu)是的形式。Concurrent表示線程安全。SkipList是一種可以代替平衡樹的數(shù)據(jù)結(jié)構(gòu)，默認(rèn)是按照Key值升序的。對于ConcurrentSkipListMap的操作的時(shí)間復(fù)雜度平均在O(logn)，設(shè)置KeyValue.
KVComparator比較KeyValue中Key的順序。
寫入MemStore中的KV，被記錄在kvset中。根據(jù)JVM內(nèi)存的垃圾回收策略，在如下條件會(huì)觸發(fā)Full GC。
? 內(nèi)存滿或者觸發(fā)閾值。
? 內(nèi)存碎片過多，造成新的分配找不到合適的內(nèi)存空間。
RS上服務(wù)多個(gè)Region，如果不對KV的分配空間進(jìn)行控制的話，由于訪問的無序性以及KV長度的不同，每個(gè)Region上的KV會(huì)無規(guī)律地分散在內(nèi)存上。Region執(zhí)行了MemStore的Flush操作，再經(jīng)過JVM GC之后就會(huì)出現(xiàn)零散的內(nèi)存碎片現(xiàn)象，而進(jìn)一步數(shù)據(jù)大量寫入，就會(huì)觸發(fā)Full-GC。圖(5)顯示這種假設(shè)場景的內(nèi)存分配過程。
為了解決因?yàn)閮?nèi)存碎片造成的Full-GC的現(xiàn)象，RegionServer引入了MSLAB（HBASE-3455）。MSLAB全稱是MemStore-Local Allocation Buffers。它通過預(yù)先分配連續(xù)的內(nèi)存塊，把零散的內(nèi)存申請合并，有效改善了過多內(nèi)存碎片導(dǎo)致的Full GC問題。
MSLAB的工作原理如下：
? 在MemStore初始化時(shí)，創(chuàng)建MemStoreLAB對象allocator。
? 創(chuàng)建一個(gè)2M大小的Chunk數(shù)組，偏移量起始設(shè)置為0。Chunk的大小可以通過參數(shù)hbase.hregion.memstore.mslab.chunksize調(diào)整。
? 當(dāng)MemStore有KeyValue加入時(shí)，maybeCloneWithAllocator(KeyValue)函數(shù)調(diào)用allocator為其查找KeyValue.getBuffer()大小的空間，若KeyValue的大小低于默認(rèn)的256K，會(huì)嘗試在當(dāng)前Chunk下查找空間，如果空間不夠，MemStoreLAB重新申請新的Chunk。選中Chunk之后，會(huì)修改offset=原偏移量+KeyValue.getBuffer().length。chunk內(nèi)控制每個(gè)KeyValue大小由hbase.hregion.memstore.mslab.max.allocation配置。
? 空間檢查通過的KeyValue，會(huì)拷貝到Chunk的數(shù)據(jù)塊中。此時(shí)，原KeyValue由于不再被MemStore引用，會(huì)在接下來的JVM的Minor GC被清理。
注意：
設(shè)置chunk的默認(rèn)大小以及對于KeyValue大小控制的原因在于，MSLAB雖然會(huì)降低內(nèi)存碎片造成的Full-GC的風(fēng)險(xiǎn)，但是它的使用會(huì)降低內(nèi)存的利用率。如果超過一定大小的KeyValue，此時(shí)該KeyValue空間被回收之后，碎片現(xiàn)象不明顯。因此，MSLAB只解決小KV的聚合。
MSLAB解決了因?yàn)樗槠斐蒄ull GC的問題，然而在MemStore被Flush到文件系統(tǒng)時(shí)，沒有reference的chunk，需要GC來進(jìn)行回收，因此，在更新操作頻繁發(fā)生時(shí)，會(huì)造成較多的Young GC。
針對該問題，HBASE-8163提出了MemStoreChunkPool的解決方案，方案已經(jīng)被HBase-0.95版本接收。它的實(shí)現(xiàn)思路：
? 創(chuàng)建chunk池來管理沒有被引用的chunk，不再依靠JVM的GC回收。
? 當(dāng)一個(gè)chunk沒有引用時(shí)，會(huì)被放入chunk池。
? chunk池設(shè)置閾值，如果超過了，則會(huì)放棄放入新的chunk到chunk池。
? 如果當(dāng)需要新的chunk時(shí)，首先從chunk池中獲取。
根據(jù)patch的測試顯示，配置MemStoreChunkPool之后，YGC降低了40%，寫性能有5%的提升。如果是0.95以下版本的用戶，可以參考HBASE-8163給出patch。
思考
通過MemStore提供的MSLAB和MemStoreChunkPool給出的解決方案，可以看出在涉及到大規(guī)模內(nèi)存的Java應(yīng)用中，如何有效地管理內(nèi)存空間，降低JVM
GC對于系統(tǒng)性能造成的影響，成為了一個(gè)研究熱點(diǎn)。整體上來說，一是設(shè)置與應(yīng)用相適應(yīng)的JVM啟動(dòng)參數(shù)，打印GC相關(guān)的信息，實(shí)時(shí)監(jiān)控GC對于服務(wù)的影響；二是從應(yīng)用程序設(shè)計(jì)層面，盡可能地友好地利用內(nèi)存，來降低GC的影響。
在ChunkPool就是幫助JVM維護(hù)了chunk信息，并把那些已經(jīng)不再M(fèi)emStore中的數(shù)據(jù)的chunk重新投入使用。這樣就可以避免大量的YGC。
3.2 MemStore參數(shù)控制原理與調(diào)優(yōu)
對于任何一個(gè)HBase集群而言，都需要根據(jù)應(yīng)用特點(diǎn)對其系統(tǒng)參數(shù)進(jìn)行配置，以達(dá)到更好的使用效果。MemStore作為更新數(shù)據(jù)的緩存，它的大小及處理方式的調(diào)整，會(huì)極大地影響到寫數(shù)據(jù)的性能、以及隨之而來的Flush、Compaction等功能。這種影響的原因在于以下兩個(gè)方面。
? RS全局的MemStore的大小與Region規(guī)模以及Region寫數(shù)據(jù)頻度之間的關(guān)系。
? 過于頻繁的Flush操作對于讀數(shù)據(jù)的影響。
這其中涉及到的可調(diào)整的參數(shù)如下表。
表MemStore相關(guān)的配置參數(shù)
參數(shù)名稱參數(shù)含義默認(rèn)值
hbase.regionserver.global.memstore.upperLimitRS內(nèi)所有MemStore的總和的上限/Heap Size的比例，超過該值，阻塞update，強(qiáng)制執(zhí)行Flush操作。0.4
hbase.regionserver.global.memstore.lowerLimit執(zhí)行Flush操作釋放內(nèi)存空間，需要達(dá)到的比例。0.35
hbase.hregion.memstore.flush.size每個(gè)MemStore占用空間的最大值，超過該值會(huì)執(zhí)行Flush操作。128MB
hbase.hregion.memstore.block.multiplierHRegion的更新被阻塞的MemStore容量的倍數(shù)。2
hbase.hregion.preclose.flush.size關(guān)閉Region之前需要執(zhí)行Flush操作的MemStore容量閾值。5MB
對于上述參數(shù)理解：
（1）RS控制內(nèi)存使用量的穩(wěn)定。
例如，假設(shè)我們的RS的內(nèi)存設(shè)置為10GB，按照以上參數(shù)的默認(rèn)值，RS用以MemStore的上限為4GB，超出之后，會(huì)阻塞整個(gè)RS的所有Reigon的請求，直到全局的MemStore總量回落到正常范圍之內(nèi)。
以上涉及到cacheFlusher在MemStore總量使用超過上限時(shí)，選擇Region進(jìn)行Flush的算法，由MemStoreFlusher.flushOneForGlobalPressure()算法實(shí)現(xiàn)。算法的處理流程如下。
關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)：
SortedMapregionsBySize=server.getCopyOfOnlineRegionsSortedBySize();//從RS上獲取在線的Region，以及它們在MemStore上使用量，并按照MemStore使用量作為Key，降序。SetexcludedRegions=newHashSet();//記錄嘗試執(zhí)行Flush操作失敗的Region…HRegion bestFlushableRegion=getBiggestMemstoreRegion(regionsBySize, excludedRegions,true);//選出storefile個(gè)數(shù)不超標(biāo)、當(dāng)前MemStore使用量最大的RegionHRegion bestAnyRegion=getBiggestMemstoreRegion(regionsBySize, excludedRegions,false);//選出當(dāng)前MemStore使用量最大的Region
步驟1：RS上在線的Region，按照當(dāng)前MemStore的使用量進(jìn)行排序，并存儲在regionsBySize中。
步驟2：選出Region下的Store中的StoreFile的個(gè)數(shù)未達(dá)到hbase.hstore.blockingStoreFiles，并且MemStore使用量最大的Region，存儲到bestFlushableRegion。
步驟3:選出Region下的MemStore使用量最大的Region，存儲到bestAnyRegion對象。
步驟4：如果bestAnyRegion的memstore使用量超出了bestFlushableRegion的兩倍，這從另外一個(gè)角度說明，雖然當(dāng)前bestAnyRegion有超過blockingStoreFiles個(gè)數(shù)的文件，但是考慮到RS內(nèi)存的壓力，冒著被執(zhí)行Compaction的風(fēng)險(xiǎn)，也選擇這個(gè)Region作為regionToFlush，因?yàn)槭找娲?。否則，直接選擇bestFlushableRegion作為regionToFlush。
步驟5：對regionToFlush執(zhí)行flush操作。如果操作失敗，regionToFlush放入excludedRegions，避免該Region下次再次被選中，然后返回步驟2執(zhí)行，否則程序退出。
（2）設(shè)置兩個(gè)limit，盡可能減少因?yàn)榭刂苾?nèi)存造成數(shù)據(jù)更新流程的阻塞。
當(dāng)RS的MemStore使用總量超過(Heap*hbase.regionserver.global.memstore.lowerLimit)的大小時(shí)，同樣會(huì)向cacheFlusher提交一個(gè)Flush請求，并以（1）中Region選擇算法，對其進(jìn)行Flush操作。與（1）不同，這個(gè)過程中RS不會(huì)阻塞RS的寫請求。
因此，在生產(chǎn)環(huán)境中，我們肯定不希望更新操作被block，一般會(huì)配置(upperLimit –lowerlimit)的值在[0.5,0.75]之間，如果是應(yīng)用寫負(fù)載較重，可以設(shè)置區(qū)間內(nèi)較大的值。
3.3 StoreFile—HFile
該節(jié)請參考：HFile文件格式與HBase讀寫
3.4 Compaction對于服務(wù)的影響
該小節(jié)請參考：深入分析HBase Compaction機(jī)制
