HBase客戶端Rpc的重試機制以及客戶端參數優化。

hbase客戶端重試機制如何保證系統的容錯性和低延遲性
HBase客戶端Rpc的重試機制以及客戶端參數優化。
HBase客戶端基于退避算法的重試機制
1、業務用戶一方面比較關注HBase本身服務的讀寫性能：吞吐量以及讀寫延遲，
2、另一方面也會比較關注HBase客戶端使用上的問題，主要集中在兩個方面：是否提供了重試機制來保證系統操作的容錯性？是否有必要的超時機制保證系統能夠fastfail，保證系統的低延遲特性？
3、HBase客戶端提供的重試機制，并通過配置合理的參數使得客戶端在保證一定容錯性的同時還能夠保證系統的低延遲特性。

RpcRetryingCall函數是Rpc請求重試機制的實現，所以可以有兩點推斷：
1、HBase客戶端請求在那個時間段網絡有異常導致rpc請求失敗，進入重試邏輯
2、根據HBase的重試機制（退避機制），每兩次重試機制之間會休眠一段時間，即上圖115行代碼，這個休眠時間太長導致這個線程一直處于TIME_WAITING狀態。

出現的將近幾個小時的堵塞無請求，除非2中情況
情況1：配置有問題：需要客戶端檢查hbase.client.pause和hbase.client.retries.number兩個參數配置出現異常，比如hbase.client.pause參數如果手抖配成了10000，就有可能出現幾個小時阻塞的情況
//
HBase 客戶端暫停
hbase.client.pause = 100 毫秒 默認
HBase 客戶端最大重試次數
hbase.client.retries.number = 35 默認次數

情況2：網絡持續有問題：如果線程1持有全局鎖重試失敗之后退出，線程2競爭到這把鎖，此時網絡依然有問題，線程2會再次進入重試，重試8min之后失敗退出，循環下去，也有可能出現幾個小時阻塞的情況
//小結：情況1 出現的概率很低，基本上出現 客戶端請求無響應，堵塞無請求的情況，網絡持續有問題是很大的原因。
通過監控和小伙伴確認之后發現：在事發當時（凌晨0點～早上6點）確實存在很多服務因為云網絡升級異常發生抖動的情況出現。

HBase Rpc重試機制

HBase的重試機制是這次異常發生的關鍵點，有必要對其進行一次解析。HBase執行rpc失敗之后會執行重試操作，
重試的最大次數可以通過配置文件配置，對應的參數為hbase.client.retries.number,0.98版本中該參數的默認值為31。
//在一定時間內，不斷的重試后，還沒有成功響應的話，最后會放棄連接到集群

客戶端參數優化實踐

很顯然，根據上面第二部分和第三部分的介紹，一旦在網絡出現抖動的異常情況下，默認最差情況下一個線程會存在8min左右的重試時間，從而會導致其他線程都阻塞在regionLockObject這把全局鎖上。為了構建一個更穩定、低延遲的HBase系統，除過需要對服務器端參數做各種調整外，客戶端參數也需要做相應的調整：

1. hbase.client.pause:默認為100，可以減少為50
   //cdh中 HBase 客戶端暫停
   hbase.client.pause = 100毫秒
2. hbase.client.retries.number:默認為31，可以減少為21
   //HBase 客戶端最大重試次數
   hbase.client.retries.number = 35

修改后，通過上面算法可以計算出每次連接集群重試之間的暫停時間將依次為：
［50，100，150，250，500，1000，2000，5000，5000，5000，5000，10000，10000，…，10000］
客戶端將會在2min內重試20次，然后放棄連接到集群，進而會再將全局鎖交給其他線程，執行其他請求。

詳細講解了HBase Rpc的重試機制以及客戶端參數優化。

參考鏈接
HBase最佳實踐 – 客戶端重試機制 http://hbasefly.com/2016/06/04/hbase-client-1/