HBase客戶端實踐重試機(jī)制
大?。?/span>0.6 MB 人氣: 2017-10-10 需要積分:1
標(biāo)簽:Hbase(11036)
現(xiàn)在,網(wǎng)易視頻云與大家分享HBase客戶端實踐–重試機(jī)制。在運維HBase的這段時間里,發(fā)現(xiàn)業(yè)務(wù)用戶一方面比較關(guān)注HBase本身服務(wù)的讀寫性能:吞吐量以及讀寫延遲,另一方面也會比較關(guān)注HBase客戶端使用上的問題,主要集中在兩個方面:是否提供了重試機(jī)制來保證系統(tǒng)操作的容錯性?是否有必要的超時機(jī)制保證系統(tǒng)能夠fastfail,保證系統(tǒng)的低延遲特性?
這個系列我們集中介紹HBase客戶端使用上的這兩大問題,本文通過分析之前一個真實的案例來介紹HBase客戶端提供的重試機(jī)制,并通過配置合理的參數(shù)使得客戶端在保證一定容錯性的同時還能夠保證系統(tǒng)的低延遲特性。
案發(fā)現(xiàn)場
最近某業(yè)務(wù)在使用HBase客戶端讀取數(shù)據(jù)時出現(xiàn)了大量線程block的情況,業(yè)務(wù)方保留了當(dāng)時的線程堆棧信息,如下圖所示:
看到這樣的問題,首先從日志和監(jiān)控排查了業(yè)務(wù)表和region server,確認(rèn)了在很長時間內(nèi)確實沒有請求進(jìn)來,除此之外并沒有其他有用的信息,同時也沒有接到該集群上其他用戶的異常反饋,從現(xiàn)象看,這次異常是在特定環(huán)境下才會觸發(fā)的。
案件分析過程
1.根據(jù)上圖圖1所示,所有的請求都block在《0x0000000782a936f0》這把全局鎖上,這里需要關(guān)注兩個問題:
哪個線程持有了這把全局鎖《0x0000000782a936f0》?
這是一把什么樣的全局鎖(對于問題本身并不重要,有興趣可以參考步驟3)?
2.哪個線程持有了這把鎖?
2.1 很容易在jstack日志中通過搜索找到全局鎖《0x0000000782a936f0》被如下線程持有:
定睛一看,該線程持有了這把全局鎖,而且處于TIMED_WAITING狀態(tài),因此這把鎖可能長時間不釋放,導(dǎo)致所有需要這把全局鎖的線程都阻塞等待。好了,那問題就轉(zhuǎn)化成了:為什么這個線程會處于TIME_WAITING狀態(tài)?
2.2 根據(jù)上圖提示,查看源碼中RpcRetryingCall.java的115行代碼,可以確定該線程處于TIME_WAITING狀態(tài)是因為自己休眠導(dǎo)致,如下圖所示:
RpcRetryingCall函數(shù)是Rpc請求重試機(jī)制的實現(xiàn),所以可以有兩點推斷:
HBase客戶端請求在那個時間段網(wǎng)絡(luò)有異常導(dǎo)致rpc請求失敗,進(jìn)入重試邏輯
根據(jù)HBase的重試機(jī)制(退避機(jī)制),每兩次重試機(jī)制之間會休眠一段時間,即上圖115行代碼,這個休眠時間太長導(dǎo)致這個線程一直處于TIME_WAITING狀態(tài)。
休眠時間由上圖中expectedSleep = callable.sleep(pause,tries + 1)決定,根據(jù)hbase算法(見第三部分),默認(rèn)最大的expectedSleep為20s,整個重試時間會持續(xù)8min,這也就是說全局鎖會被持有8min,可這并不能解釋持續(xù)將近幾個小時的阻塞無請求。除非有兩種情況:
配置有問題:需要客戶端檢查hbase.client.pause和hbase.client.retries.number兩個參數(shù)配置出現(xiàn)異常,比如hbase.client.pause參數(shù)如果手抖配成了10000,就有可能出現(xiàn)幾個小時阻塞的情況
網(wǎng)絡(luò)持續(xù)有問題:如果線程1持有全局鎖重試失敗之后退出,線程2競爭到這把鎖,此時網(wǎng)絡(luò)依然有問題,線程2會再次進(jìn)入重試,重試8min之后失敗退出,循環(huán)下去,也有可能出現(xiàn)幾個小時阻塞的情況
和業(yè)務(wù)方確認(rèn)配置,所有參數(shù)基本屬于默認(rèn)配置,因此猜測一不成立,那最有可能的情況就是猜測二。經(jīng)過確認(rèn),在事發(fā)當(dāng)時(凌晨0點~早上6點)確實存在很多服務(wù)因為云網(wǎng)絡(luò)升級異常發(fā)生抖動的情況出現(xiàn)。然而因為沒有具體的日志信息,所以并不能完全確認(rèn)猜測是否正確。但是,通過問題的分析可以進(jìn)一步明白HBase重試機(jī)制以及部分客戶端參數(shù)優(yōu)化策略,這也是寫這篇文章的初衷之一。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%
下載地址
HBase客戶端實踐重試機(jī)制下載
相關(guān)電子資料下載
- 【分布式存儲數(shù)據(jù)恢復(fù)】hbase和hive數(shù)據(jù)庫底層文件誤刪的恢復(fù)案例 415
- 使用G1 GC時HBase為什么性能下降了近20% 1653
- Hbase的基礎(chǔ)性介紹與入門 1046
- 阿里HBase高可用8年“抗戰(zhàn)”回憶錄 246
- 阿里云HBase推出普惠性高可用服務(wù),獨家支持用戶的自建、混合云環(huán)境集群 205
- 今年小米做東,HBaseCon Asia 2019將在北京召開 2893
- 基于HBase的工業(yè)大數(shù)據(jù)存儲實戰(zhàn) 3130
- 阿里云HBase推出全新X-Pack服務(wù) 定義HBase云服務(wù)新標(biāo)準(zhǔn) 123
- 阿里云HBase全新發(fā)布X-Pack NoSQL數(shù)據(jù)庫再上新臺階 231
- 八年技術(shù)加持,性能提升10倍,阿里云HBase 2.0首發(fā)商用 130