一、Hbase整個寫入流程
client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem
整個寫入流程從客戶端調用API開始，數據會通過protobuf編碼成一個請求，通過scoket實現的IPC模塊被送達server的RPC隊列中。最后由負責處理RPC的handler取出請求完成寫入操作。寫入會先寫WAL文件，然后再寫一份到內存中，也就是memstore模塊，當滿足條件時，memstore才會被flush到底層文件系統，形成HFile。
二、當寫入過快時會遇見什么問題
HBase會檢查Memstore的大小，如果Memstore超過設定的blockingMemStoreSize則觸發flush的操作，並拋出RegionTooBusyException，阻塞寫操作的進行。如下源碼所示：
private void checkResources() throws RegionTooBusyException { // If catalog region, do not impose resource constraints or block updates. // 如果是Meta Region，不實施資源約束或阻塞更新 if (this.getRegionInfo().isMetaRegion()) return; // 如果Region當前內存大小超過閾值 // 這個memstoreSize是當前時刻HRegion上MemStore的大小，它是在Put、Append等操作中調用addAndGetGlobalMemstoreSize()方法實時更新的。 // 而blockingMemStoreSize是HRegion上設定的MemStore的一個閾值，當MemStore的大小超過這個閾值時，將會阻塞數據更新操作 if (this.memstoreSize.get() > this.blockingMemStoreSize) { // 更新阻塞請求計數器 blockedRequestsCount.increment(); // 請求刷新Region requestFlush(); // 拋出RegionTooBusyException異常 throw new RegionTooBusyException("Above memstore limit, " + "regionName=" + (this.getRegionInfo() == null ? "unknown" : this.getRegionInfo().getRegionNameAsString()) + ", server=" + (this.getRegionServerServices() == null ? "unknown" : this.getRegionServerServices().getServerName()) + ", memstoreSize=" + memstoreSize.get() + ", blockingMemStoreSize=" + blockingMemStoreSize); } }
blockingMemStoreSize的大小由hbase.hregion.memstore.flush.size和hbase.hregion.memstore.block.multiplier共同作用，等於兩者相乘，我們的hbase.hregion.memstore.flush.size設置的是256M，hbase.hregion.memstore.block.multiplier設置的是3，因此：blockingMemStoreSize=805306368。具體的blockingMemStoreSize計算的代碼如下：
this.blockingMemStoreSize = this.memstoreFlushSize * conf.getLong(HConstants.HREGION_MEMSTORE_BLOCK_MULTIPLIER, HConstants.DEFAULT_HREGION_MEMSTORE_BLOCK_MULTIPLIER);
寫入過快時，memstore的水位會馬上被推高。
你可能會看到以下類似日志：
RegionTooBusyException: Above memstore limit, regionName=xxxxx ...
這個是Region的memstore占用內存大小超過正常的4倍，這時候會拋異常，寫入請求會被拒絕，客戶端開始重試請求。當達到128M的時候會觸發flush memstore，當達到128M * 4還沒法觸發flush時候會拋異常來拒絕寫入。兩個相關參數的默認值如下：
hbase.hregion.memstore.flush.size=128M hbase.hregion.memstore.block.multiplier=4
或者這樣的日志：
regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms
這是所有region的memstore內存總和開銷超過配置上限，默認是配置heap的40%，這會導致寫入被阻塞。目的是等待flush的線程把內存里的數據flush下去，否則繼續允許寫入memestore會把內存寫爆
hbase.regionserver.global.memstore.upperLimit=0.4 # 較舊版本，新版本兼容 hbase.regionserver.global.memstore.size=0.4 # 新版本
當寫入請求由於達到memstore上限而被阻塞，隊列會開始積壓，如果運氣不好最后會導致OOM，你可能會發現JVM由於OOM crash或者看到如下類似日志：
ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x java.lang.OutOfMemoryError: Java heap space
HBase這里我認為有個很不好的設計，捕獲了OOM異常卻沒有終止進程。這時候進程可能已經沒法正常運行下去了，你還會在日志里發現很多其它線程也拋OOM異常。比如stop可能根本stop不了，RS可能會處於一種僵死狀態。
三、如何避免RS OOM？
一種是加快flush速度：
hbase.hstore.blockingWaitTime = 90000 ms hbase.hstore.flusher.count = 2 hbase.hstore.blockingStoreFiles = 10
當達到hbase.hstore.blockingStoreFiles配置上限時，會導致flush阻塞等到compaction工作完成。阻塞時間是hbase.hstore.blockingWaitTime，可以改小這個時間。hbase.hstore.flusher.count可以根據機器型號去配置，可惜這個數量不會根據寫壓力去動態調整，配多了，非導入數據多場景也沒用，改配置還得重啟。
同樣的道理，如果flush加快，意味這compaction也要跟上，不然文件會越來越多，這樣scan性能會下降，開銷也會增大。
hbase.regionserver.thread.compaction.small = 1 hbase.regionserver.thread.compaction.large = 1
增加compaction線程會增加CPU和帶寬開銷，可能會影響正常的請求。如果不是導入數據，一般而言是夠了。好在這個配置在雲HBase內是可以動態調整的，不需要重啟。
上述配置都需要人工干預，如果干預不及時server可能已經OOM了，這時候有沒有更好的控制方法？
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G
直接限制隊列堆積的大小。當堆積到一定程度后，事實上后面的請求等不到server端處理完，可能客戶端先超時了。並且一直堆積下去會導致OOM，1G的默認配置需要相對大內存的型號。當達到queue上限，客戶端會收到CallQueueTooBigException 然后自動重試。通過這個可以防止寫入過快時候把server端寫爆，有一定反壓作用。線上使用這個在一些小型號穩定性控制上效果不錯。