hbase客戶端重試機制如何保證系統(tǒng)的容錯性和低延遲性
HBase客戶端Rpc的重試機制以及客戶端參數(shù)優(yōu)化。
HBase客戶端基于退避算法的重試機制
1、業(yè)務用戶一方面比較關(guān)注HBase本身服務的讀寫性能：吞吐量以及讀寫延遲，
2、另一方面也會比較關(guān)注HBase客戶端使用上的問題，主要集中在兩個方面：是否提供了重試機制來保證系統(tǒng)操作的容錯性？是否有必要的超時機制保證系統(tǒng)能夠fastfail，保證系統(tǒng)的低延遲特性？
3、HBase客戶端提供的重試機制，并通過配置合理的參數(shù)使得客戶端在保證一定容錯性的同時還能夠保證系統(tǒng)的低延遲特性。
創(chuàng)新互聯(lián)主要從事網(wǎng)站設計、成都網(wǎng)站制作、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務武陵,10多年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:13518219792
RpcRetryingCall函數(shù)是Rpc請求重試機制的實現(xiàn)，所以可以有兩點推斷：
1、HBase客戶端請求在那個時間段網(wǎng)絡有異常導致rpc請求失敗，進入重試邏輯
2、根據(jù)HBase的重試機制（退避機制），每兩次重試機制之間會休眠一段時間，即上圖115行代碼，這個休眠時間太長導致這個線程一直處于TIME_WAITING狀態(tài)。
出現(xiàn)的將近幾個小時的堵塞無請求，除非2中情況
情況1：配置有問題：需要客戶端檢查hbase.client.pause和hbase.client.retries.number兩個參數(shù)配置出現(xiàn)異常，比如hbase.client.pause參數(shù)如果手抖配成了10000，就有可能出現(xiàn)幾個小時阻塞的情況
//
HBase 客戶端暫停
hbase.client.pause = 100 毫秒 默認
HBase 客戶端最大重試次數(shù)
hbase.client.retries.number = 35 默認次數(shù)
情況2：網(wǎng)絡持續(xù)有問題：如果線程1持有全局鎖重試失敗之后退出，線程2競爭到這把鎖，此時網(wǎng)絡依然有問題，線程2會再次進入重試，重試8min之后失敗退出，循環(huán)下去，也有可能出現(xiàn)幾個小時阻塞的情況
//小結(jié)：情況1 出現(xiàn)的概率很低，基本上出現(xiàn) 客戶端請求無響應，堵塞無請求的情況，網(wǎng)絡持續(xù)有問題是很大的原因。
通過監(jiān)控和小伙伴確認之后發(fā)現(xiàn)：在事發(fā)當時（凌晨0點～早上6點）確實存在很多服務因為云網(wǎng)絡升級異常發(fā)生抖動的情況出現(xiàn)。
HBase的重試機制是這次異常發(fā)生的關(guān)鍵點，有必要對其進行一次解析。HBase執(zhí)行rpc失敗之后會執(zhí)行重試操作，
重試的最大次數(shù)可以通過配置文件配置，對應的參數(shù)為hbase.client.retries.number,0.98版本中該參數(shù)的默認值為31。
//在一定時間內(nèi)，不斷的重試后，還沒有成功響應的話，最后會放棄連接到集群
很顯然，根據(jù)上面第二部分和第三部分的介紹，一旦在網(wǎng)絡出現(xiàn)抖動的異常情況下，默認最差情況下一個線程會存在8min左右的重試時間，從而會導致其他線程都阻塞在regionLockObject這把全局鎖上。為了構(gòu)建一個更穩(wěn)定、低延遲的HBase系統(tǒng)，除過需要對服務器端參數(shù)做各種調(diào)整外，客戶端參數(shù)也需要做相應的調(diào)整：
修改后，通過上面算法可以計算出每次連接集群重試之間的暫停時間將依次為：
［50，100，150，250，500，1000，2000，5000，5000，5000，5000，10000，10000，…，10000］
客戶端將會在2min內(nèi)重試20次，然后放棄連接到集群，進而會再將全局鎖交給其他線程，執(zhí)行其他請求。
詳細講解了HBase Rpc的重試機制以及客戶端參數(shù)優(yōu)化。
參考鏈接
HBase最佳實踐 – 客戶端重試機制 http://hbasefly.com/2016/06/04/hbase-client-1/
重慶分公司
重慶分公司
