您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費注冊]

您的位置:電子發(fā)燒友網(wǎng)>源碼下載>數(shù)值算法/人工智能>

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

大?。?/span>0.6 MB 人氣: 2017-10-10 需要積分:1
現(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)時的線程堆棧信息,如下圖所示:
  HBase客戶端實踐重試機(jī)制
  看到這樣的問題,首先從日志和監(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》被如下線程持有:
  HBase客戶端實踐重試機(jī)制
  定睛一看,該線程持有了這把全局鎖,而且處于TIMED_WAITING狀態(tài),因此這把鎖可能長時間不釋放,導(dǎo)致所有需要這把全局鎖的線程都阻塞等待。好了,那問題就轉(zhuǎn)化成了:為什么這個線程會處于TIME_WAITING狀態(tài)?
  2.2 根據(jù)上圖提示,查看源碼中RpcRetryingCall.java的115行代碼,可以確定該線程處于TIME_WAITING狀態(tài)是因為自己休眠導(dǎo)致,如下圖所示:
  HBase客戶端實踐重試機(jī)制
  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%

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關(guān)規(guī)定!

      ?