HBase 如何減少更新時重新開機rs節點造成的影響

最近被問到這個問題，一時沒有很好的回答，事後仔細思考了下，整理如下。

rs節點重新開機對于應用的影響可分為如下2個階段：

1. region不可用
2. region讀取慢

不可用的優化

從rs停止到各個region重新上線前都處于不可用階段，其中包含了master感覺到有rs退出，進而排程執行scp的過程，詳細的過程可以參考我的另外一篇文章《

HBase2.0 regionServer退出處理流程

》，尤其是末尾連結中的詳細流程圖；

而不可用階段最為耗時的部分應該是scp的執行階段，其核心部分僞代碼如下：

if(carryingMeta)
{
    split meta log;
    assign meta region;
    wait meta loaded;
}

split log;
assign reigons;           

是以減少不可用的時間主要就是簡化上述過程，可用的手段有如下2個：

1. 重新開機rs前先執行flush，進而減少split log以及後續replay log所需的時間；
2. 重新開機rs前先把region move到其它節點去，這個方法需要擷取region資訊并且要自己指定目标節點，稍微麻煩一些，但是效果更徹底，因為完全不受scp執行時間影響，不可用時間縮減到1個ap的時間；

還有就是利用region replica特性，在主region不可用階段，也能夠利用副本提供讀服務，這個方法的缺點，1是副本要消耗額外的io和記憶體資源，2是寫請求依然不可用；

讀取慢的優化

讀取慢的原因，1是在新的rs上region的locality很可能會降低，2是blockcache是空的；

locality的問題，正常情況下在rs重新開機完成後，balancer會基于locality的考慮将region遷移回原rs，但由于balance的過程還受其它因素影響，是以也并不必然，是以還是主動move更好一些；

如果已将自動balance關閉, 那主動move回原節點就是自然而然的了；

blockcache的問題，可以考慮在rs停止前将其儲存在本地磁盤上，重新啟動時進行加載，印象中之前看過一篇分享文章中提到過這個優化；