1、Master负载并不很高，基本采用热备的方式来实现Master高可用
2、RegionServer宕机的恢复主要原因有。
2.1、Full GC异常
2.2、HDFS异常
2.3、物理节点宕机
2.4、HBase Bug
3、RegionServer故障恢复原理
3.1、利用ZK临时节点机制，RS在启动会在ZK注册成临时节点，同时Master会Watch这个节点，一般情况下RegionServe会周期性的向ZK发送心跳，如果在超时时间内没有收到心跳，临时节点就会离线，这个消息马上会通知给到Master,Master检测到RS宕机
3.2、切分未持久化的HLog日志，HLog包含多个Region的数据，为了能够按照Region一个个进行数据恢复，首先需要对HLog按照Region进行分组。把同一个Region的日志放一块，便于一个个Region回放。
3.3、Master重新分配宕机RegionServer上的region,将这些Region重新分配到其他可用的RS上。
3.4、按照Region回放HLog
3.5、完成修复，对外提供服务
4、HLog切分大有学问
4.1、0.96版本之前的切分策略:Master单机切分HLog
4.1.1、将待切分的日志重命名，主要防止在某些情况下RS并没有真正宕机，但是Master已经在进行故障恢复了，但是RS还在接受写入请求导致数据不一致。重命名之后此时用户的请求就会异常终止。
4.1.2、读取HLog数据对数据按照Region分组。
4.1.3、切分完成之后Master会对每个Region HLog数据写入各个Region对应的HDFS目录。
4.1.4、Region对日志按顺序进行会回放。
缺点：如果需要恢复的数据有几十G 或者更大，Master单机切片的搞法可能需要数小时。
4.2、分布式切分HLog策略
4.2.1、Master将待切分的日志路径发布到ZK节点上，每个日志为一个任务，每个任务都有对应的状态，起始状态为TASK_UNASSIGNED
4.2.2、RS启动之后都注册这个节点等待新任务，一旦Master发布任务，RS就会抢占该任务
4.2.3、抢占任务先看任务状态，如果是TASK_UNASSIGNED，则说明没有被抢占，然后尝试去修改状态为TASK_OWEND，如果修改成功，表名任务抢占成功。如果修改失败说明被别的RS抢占了。
4.2.4、RS抢占任务成功了之后，将任务分给相应的线程处理，如果处理成功则修改状态为TASK_DONE;如果失败，则状态修改为TASK_ERR。
4.2.5、Master一直监听ZK节点状态的变更，如果状态为TASK_ERR,则重新发布任务，如果成功则删除对应的节点。
4.2.6、分布式切分举例
1）假设Master当前发布了4个任务，即当前需要回放4个日志文件HLog1(H1)、HLog2(H2)、HLog3(H3)、Hlog4(h4)
2）假设RS1抢占了H1,H2；RS2抢占了H3；RS3抢占到了H4
3）以RS1为例，他会把H1，H2，分给2个HlogSpliter线程进行处理，HLogSpliter负责对日志文件执行具体的切分，
具体切分步骤用4.1策略差不多
优点：通过多RS同时执行HLog切分，解决了Master单机切分带来的耗时长的问题
缺点：假设一个宕机的RS上有200个Region,有90个Hlog,由于每个HLog都需要按Region分组，所以这种切分方法会产生90*200=18 000 个小文件。
4.4、分布式日志回放策略
相比分布式切分HLog策略，流程上主要改动了两点
1）、不是先切分在分配Region，而是先分配Region之后再进行Hlog切分，并且此时的Region是recovering状态，可以对外提供写服务
2）、切分HLog逻辑同4.2区别是分布式回放策略并没有先写入文件，而是直接回放。
这种设计大大减少小文件的IO消耗，解决4.2的短板。
