HBase客戶端實(shí)踐重試機(jī)制

現(xiàn)在，網(wǎng)易視頻云與大家分享HBase客戶端實(shí)踐–重試機(jī)制。
　　在運(yùn)維HBase的這段時(shí)間里，發(fā)現(xiàn)業(yè)務(wù)用戶一方面比較關(guān)注HBase本身服務(wù)的讀寫(xiě)性能：吞吐量以及讀寫(xiě)延遲，另一方面也會(huì)比較關(guān)注HBase客戶端使用上的問(wèn)題，主要集中在兩個(gè)方面：是否提供了重試機(jī)制來(lái)保證系統(tǒng)操作的容錯(cuò)性？是否有必要的超時(shí)機(jī)制保證系統(tǒng)能夠fastfail，保證系統(tǒng)的低延遲特性？
　　這個(gè)系列我們集中介紹HBase客戶端使用上的這兩大問(wèn)題，本文通過(guò)分析之前一個(gè)真實(shí)的案例來(lái)介紹HBase客戶端提供的重試機(jī)制，并通過(guò)配置合理的參數(shù)使得客戶端在保證一定容錯(cuò)性的同時(shí)還能夠保證系統(tǒng)的低延遲特性。
　　案發(fā)現(xiàn)場(chǎng)
　　最近某業(yè)務(wù)在使用HBase客戶端讀取數(shù)據(jù)時(shí)出現(xiàn)了大量線程block的情況，業(yè)務(wù)方保留了當(dāng)時(shí)的線程堆棧信息，如下圖所示：
　　
　　看到這樣的問(wèn)題，首先從日志和監(jiān)控排查了業(yè)務(wù)表和region server，確認(rèn)了在很長(zhǎng)時(shí)間內(nèi)確實(shí)沒(méi)有請(qǐng)求進(jìn)來(lái)，除此之外并沒(méi)有其他有用的信息，同時(shí)也沒(méi)有接到該集群上其他用戶的異常反饋，從現(xiàn)象看，這次異常是在特定環(huán)境下才會(huì)觸發(fā)的。
　　案件分析過(guò)程
　　1.根據(jù)上圖圖1所示，所有的請(qǐng)求都block在《0x0000000782a936f0》這把全局鎖上，這里需要關(guān)注兩個(gè)問(wèn)題：
　　哪個(gè)線程持有了這把全局鎖《0x0000000782a936f0》？
　　這是一把什么樣的全局鎖（對(duì)于問(wèn)題本身并不重要，有興趣可以參考步驟3）？
　　2.哪個(gè)線程持有了這把鎖？
　　2.1 很容易在jstack日志中通過(guò)搜索找到全局鎖《0x0000000782a936f0》被如下線程持有：
　　
　　定睛一看，該線程持有了這把全局鎖，而且處于TIMED_WAITING狀態(tài)，因此這把鎖可能長(zhǎng)時(shí)間不釋放，導(dǎo)致所有需要這把全局鎖的線程都阻塞等待。好了，那問(wèn)題就轉(zhuǎn)化成了：為什么這個(gè)線程會(huì)處于TIME_WAITING狀態(tài)？
　　2.2 根據(jù)上圖提示，查看源碼中RpcRetryingCall.java的115行代碼，可以確定該線程處于TIME_WAITING狀態(tài)是因?yàn)樽约盒菝邔?dǎo)致，如下圖所示：
　　
　　RpcRetryingCall函數(shù)是Rpc請(qǐng)求重試機(jī)制的實(shí)現(xiàn)，所以可以有兩點(diǎn)推斷：
　　HBase客戶端請(qǐng)求在那個(gè)時(shí)間段網(wǎng)絡(luò)有異常導(dǎo)致rpc請(qǐng)求失敗，進(jìn)入重試邏輯
　　根據(jù)HBase的重試機(jī)制（退避機(jī)制），每?jī)纱沃卦嚈C(jī)制之間會(huì)休眠一段時(shí)間，即上圖115行代碼，這個(gè)休眠時(shí)間太長(zhǎng)導(dǎo)致這個(gè)線程一直處于TIME_WAITING狀態(tài)。
　　休眠時(shí)間由上圖中expectedSleep = callable.sleep（pause，tries + 1）決定，根據(jù)hbase算法（見(jiàn)第三部分），默認(rèn)最大的expectedSleep為20s，整個(gè)重試時(shí)間會(huì)持續(xù)8min，這也就是說(shuō)全局鎖會(huì)被持有8min，可這并不能解釋持續(xù)將近幾個(gè)小時(shí)的阻塞無(wú)請(qǐng)求。除非有兩種情況：
　　配置有問(wèn)題：需要客戶端檢查hbase.client.pause和hbase.client.retries.number兩個(gè)參數(shù)配置出現(xiàn)異常，比如hbase.client.pause參數(shù)如果手抖配成了10000，就有可能出現(xiàn)幾個(gè)小時(shí)阻塞的情況
　　網(wǎng)絡(luò)持續(xù)有問(wèn)題：如果線程1持有全局鎖重試失敗之后退出，線程2競(jìng)爭(zhēng)到這把鎖，此時(shí)網(wǎng)絡(luò)依然有問(wèn)題，線程2會(huì)再次進(jìn)入重試，重試8min之后失敗退出，循環(huán)下去，也有可能出現(xiàn)幾個(gè)小時(shí)阻塞的情況
　　和業(yè)務(wù)方確認(rèn)配置，所有參數(shù)基本屬于默認(rèn)配置，因此猜測(cè)一不成立，那最有可能的情況就是猜測(cè)二。經(jīng)過(guò)確認(rèn)，在事發(fā)當(dāng)時(shí)（凌晨0點(diǎn)～早上6點(diǎn)）確實(shí)存在很多服務(wù)因?yàn)樵凭W(wǎng)絡(luò)升級(jí)異常發(fā)生抖動(dòng)的情況出現(xiàn)。然而因?yàn)闆](méi)有具體的日志信息，所以并不能完全確認(rèn)猜測(cè)是否正確。但是，通過(guò)問(wèn)題的分析可以進(jìn)一步明白HBase重試機(jī)制以及部分客戶端參數(shù)優(yōu)化策略，這也是寫(xiě)這篇文章的初衷之一。