首先我們簡(jiǎn)單回顧下整個(gè)寫(xiě)入流程
client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem
整個(gè)寫(xiě)入流程從客戶(hù)端調(diào)用API開(kāi)始，數(shù)據(jù)會(huì)通過(guò)protobuf編碼成一個(gè)請(qǐng)求，通過(guò)scoket實(shí)現(xiàn)的IPC模塊被送達(dá)server的RPC隊(duì)列中。最后由負(fù)責(zé)處理RPC的handler取出請(qǐng)求完成寫(xiě)入操作。寫(xiě)入會(huì)先寫(xiě)WAL文件，然后再寫(xiě)一份到內(nèi)存中，也就是memstore模塊，當(dāng)滿(mǎn)足條件時(shí)，memstore才會(huì)被flush到底層文件系統(tǒng)，形成HFile。
當(dāng)寫(xiě)入過(guò)快時(shí)會(huì)遇見(jiàn)什么問(wèn)題?
寫(xiě)入過(guò)快時(shí)，memstore的水位會(huì)馬上被推高。
你可能會(huì)看到以下類(lèi)似日志：
RegionTooBusyException: Above memstore limit, regionName=xxxxx ...
這個(gè)是Region的memstore占用內(nèi)存大小超過(guò)正常的4倍，這時(shí)候會(huì)拋異常，寫(xiě)入請(qǐng)求會(huì)被拒絕，客戶(hù)端開(kāi)始重試請(qǐng)求。當(dāng)達(dá)到128M的時(shí)候會(huì)觸發(fā)flush memstore，當(dāng)達(dá)到128M * 4還沒(méi)法觸發(fā)flush時(shí)候會(huì)拋異常來(lái)拒絕寫(xiě)入。兩個(gè)相關(guān)參數(shù)的默認(rèn)值如下：
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內(nèi)存總和開(kāi)銷(xiāo)超過(guò)配置上限，默認(rèn)是配置heap的40%，這會(huì)導(dǎo)致寫(xiě)入被阻塞。目的是等待flush的線程把內(nèi)存里的數(shù)據(jù)flush下去，否則繼續(xù)允許寫(xiě)入memestore會(huì)把內(nèi)存寫(xiě)爆
hbase.regionserver.global.memstore.upperLimit=0.4 # 較舊版本，新版本兼容
hbase.regionserver.global.memstore.size=0.4 # 新版本
當(dāng)寫(xiě)入被阻塞，隊(duì)列會(huì)開(kāi)始積壓，如果運(yùn)氣不好最后會(huì)導(dǎo)致OOM，你可能會(huì)發(fā)現(xiàn)JVM由于OOM crash或者看到如下類(lèi)似日志：
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這里我認(rèn)為有個(gè)很不好的設(shè)計(jì)，捕獲了OOM異常卻沒(méi)有終止進(jìn)程。這時(shí)候進(jìn)程可能已經(jīng)沒(méi)法正常運(yùn)行下去了，你還會(huì)在日志里發(fā)現(xiàn)很多其它線程也拋OOM異常。比如stop可能根本stop不了，RS可能會(huì)處于一種僵死狀態(tài)。
如何避免RS OOM?
一種是加快flush速度：
hbase.hstore.blockingWaitTime = 90000 ms
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10
當(dāng)達(dá)到hbase.hstore.blockingStoreFiles配置上限時(shí)，會(huì)導(dǎo)致flush阻塞等到compaction工作完成。阻塞時(shí)間是hbase.hstore.blockingWaitTime，可以改小這個(gè)時(shí)間。hbase.hstore.flusher.count可以根據(jù)機(jī)器型號(hào)去配置，可惜這個(gè)數(shù)量不會(huì)根據(jù)寫(xiě)壓力去動(dòng)態(tài)調(diào)整，配多了，非導(dǎo)入數(shù)據(jù)多場(chǎng)景也沒(méi)用，改配置還得重啟。
同樣的道理，如果flush加快，意味這compaction也要跟上，不然文件會(huì)越來(lái)越多，這樣scan性能會(huì)下降，開(kāi)銷(xiāo)也會(huì)增大。
hbase.regionserver.thread.compaction.small = 1
hbase.regionserver.thread.compaction.large = 1
增加compaction線程會(huì)增加CPU和帶寬開(kāi)銷(xiāo)，可能會(huì)影響正常的請(qǐng)求。如果不是導(dǎo)入數(shù)據(jù)，一般而言是夠了。好在這個(gè)配置在云HBase內(nèi)是可以動(dòng)態(tài)調(diào)整的，不需要重啟。
上述配置都需要人工干預(yù)，如果干預(yù)不及時(shí)server可能已經(jīng)OOM了，這時(shí)候有沒(méi)有更好的控制方法?
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G
直接限制隊(duì)列堆積的大小。當(dāng)堆積到一定程度后，事實(shí)上后面的請(qǐng)求等不到server端處理完，可能客戶(hù)端先超時(shí)了。并且一直堆積下去會(huì)導(dǎo)致OOM，1G的默認(rèn)配置需要相對(duì)大內(nèi)存的型號(hào)。當(dāng)達(dá)到queue上限，客戶(hù)端會(huì)收到CallQueueTooBigException 然后自動(dòng)重試。通過(guò)這個(gè)可以防止寫(xiě)入過(guò)快時(shí)候把server端寫(xiě)爆，有一定反壓作用。線上使用這個(gè)在一些小型號(hào)穩(wěn)定性控制上效果不錯(cuò)。
我這里整理了一些大數(shù)據(jù)的學(xué)習(xí)資料，每周都有更新，大家需要的話(huà)可以加我下QQ：3300863615
