最近被问到这个问题，一时没有很好的回答，事后仔细思考了下，整理如下。

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停止前将其保存在本地磁盘上，重新启动时进行加载，印象中之前看过一篇分享文章中提到过这个优化；