分布式系统的现状，难以区分一个响应慢的节点和一个死掉的节点，所有的rpc流程都是基于timeout机制，我们期望更少的超时时间，则意味着有更高的误判率，误判的情况下hbase容错性虽然很好，但总要付出一些数据恢复的代价。

　　故障恢复主要牵涉到的组件有zk，hmaster namenode。zk承担锁机制的角色，一段时间未收到regionserver发来的心跳消息（180s），则会判断该节点发生故障，hmaster就会发起recovery流程：

　　　　1、数据恢复，namenode将未关闭的hlog文件关闭，regionserver读取hlog文件到hdfs文件系统中region对应的目录下并创建recovery.edits临时文件，region重新打开时会读取recovery.edits文件的数据，并将hfile中不存在的数据写到memory中，然后flush到hfile中。

　　　　2、assign region，处于转移状体的region会在zk的创建一个RIT节点来保存region的状态。hmaster将故障的regionserver上的region 重新分配到其他的regionserver上。

优化处理方案:

  　　　　split log优化处理，将元数据的hlog与用户表的hlog分离，优先将元数据的表恢复，以前的方案是所有的数据都是在一个hlog下，元数据表需要等到用户表数据恢复完之后才会上线，经优化后，元数据表可以优先上线，而且恢复速度快，在故障还未恢复完全的情况下，除了故障regionserver上的region不能读写其他的regionserver都能够正常提供服务。

　　　　　减少需要恢复的数据，设置定时flush定量flush memory中的数据到hdfs。

　　　　　引入datanode的stale状态，，在网络延时的情况下，datanode先感知到网络的异常，设置状态为stale，停止写入数据。regionserver不会讲stale状态的datanode当成primary来recovery，这样减少了recovery过程中datenode的等待时间。

hbase故障恢复