网易视频云：HBase–RegionServer宕机恢复原理
网易视频云是网易倾力龅歧仲半打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云与大家分享一下HBase–RegionServer宕机恢复原理和应对之道
Region Server宕机总述
HBase一个很大的特色是扩展性极其友好，可以通过简单地加机器实现集群规模的线性扩展，而且机器的配置并不需要太好，通过大量廉价机器代替价格昂贵的高性能机器。但也正因为廉价机器，由于网络硬盘等各方面的原因，机器宕机的概率就会相对比较大。RegionServer作为HBase集群中实际的执行节点，不可避免地也会出现宕机。
宕机并不十分可怕，因为不会丢数据。HBase集群中一台RegionServer宕机（实指RegionServer进程挂掉，下文同）并不会导致已经写入的数据丢失，和MySQL等数据库一样，HBase采用WAL机制保证这点：它会先写HLog，再写缓存，缓存写满后一起落盘。即使意外宕机导致很多缓存数据没有及时落盘，也可以通过HLog日志恢复出来。
可是没有数据丢失并不意味着宕机对业务方没有任何影响。众所周知，RegionServer宕机是由zookeeper首先感知到的，而zookeeper感知到RegionServer宕机事件是需要一定时间的，这段时间默认会有3min。也就是说，在RegionServer宕机之后的3min之内系统并不知晓它实际上已经宕机了，所有的读写路由还会正常落到它上面，可想而知，这些读写必然都会失败。（当然，并不是所有RegionServer宕机都需要3min中才能被Zookeeper感知。如果RegionServer在运行过程中产生自身难以解决的问题，它会自己abort自己，并且RegionServer会主动通知Zookeeper自己已经宕机的事实。这种场景下，影响用户读写的时间会极大的缩短到秒级）
Zookeeper一旦感知到RegionServer宕机之后，就会第一时间通知集群的管理者Master，Master首先会将这台RegionServer上所有Region移到其他RegionServer上，再将HLog分发给其他RegionServer进行回放，这个过程通常会很快。完成之后再修改路由，业务方的读写才会恢复正常。
既然，在分布式领域RegionServer宕机无法避免，那我们就有必要研究一旦宕机应该如何应对，即RegionServer宕机应对之道。另外，RegionServer宕机一定程度上会影响业务方的读写请求，所以我们也有必要研究如何定位宕机原因并设法避免。
Region Server宕机应对之道
理论基础
HBase底层数据存储依赖于HDFS组件，HDFS中数据是按照block块来存储，一个块默认是64M。为了实现数据不丢失，线上HDFS存储普遍为多副本存储，默认为3副本。因此一个大文件在HDFS中存储，首先会被切分成多个block块，然后每个block块会被存放到3台不同的机器上，实现3副本存储。
考虑到读性能以及数据的高可用性，HDFS在实现3副本的时候采取了一定的算法策略。HDFS总是为第一份副本优先选择本地节点作为存储空间，对于第二份副本，则是优先选择另一个机架的节点。如果前两份副本位于不同机架，第三份副本偏向于选择与第一份副本相同机架的节点，否则选择不同机架。整个写的流程如下图所示：
其中master.AssignmentManaager字段表示有多少个Region被移动到了哪个节点，上图表示有18个节点移动到hbase11节点。字段Transition表示具体的迁移Region信息，可以通过如下脚本解析这部分日志得到所有的Regions：
cat‘hbase-hadoop-master-hbase10.log’| grep‘GeneralBulkAssigner-[0-9]]master.RegionStates: Transition’| awk -F‘{‘‘{print $2}’|awk -F‘ ‘‘{print $1}’| uniq
·迁移Regions回原RegionServer：使用HBase提供的move命令可以迁移Region到原RegionServer。Region比较多的话也可以使用脚本批量迁移。
RegionServer宕机原因定位
紧急处理完宕机的RegionServer之后，就应该着手定位宕机原因，确定是否可以设法避免。所有系统Bug原因定位无非三大招，查日志、查监控、查代码。RegionServer宕机排查主要依赖前两点。下面以一个具体事例来简单说明排查RegionServer宕机的过程：线上有一个HBase集群，由4个RegionServer组成，这个集群每隔一段时间就会出现一个RegionServer宕掉的情况，首先想到排查日志，如下：
排查日志
HBase系统日志主要包括master日志（上文已提到），regionserver日志以及gc日志。很显然，regionserver宕机主要查看regionserver日志，经过排查，在对应时间点找到如下日志片段：
排查监控
系统可用端口被耗尽，立马联想到HBase所有读写HDFS操作都会发起RPC请求，如果并发RPC请求太多，会不会导致端口耗尽？带着这样的疑问排查了监控系统中这台主机的网卡流量图，如下图：
上图是节点上连接状态统计图，红线表示处于CLOSE_WAIT状态的socket数。很显然，系统中处于CLOSE_WAIT状态的socket数不断上升直至50k+，然后跳水式下跌，联想到RegionServer会每隔一段时间宕机以及端口被耗尽，这不就是规律么。显而易见，既然是周期性地宕机，我们就可以根据监控数据知道下一次宕机大约发生在什么时候，然后在发生之前平滑重启Region Server就可以保证不影响上层业务请求。
但是，这并没有说明宕机的真正原因，但是却给了我们足够多的提示信息。带着CLOSE_WAIT关键字，在HBase官方Jira上一搜就很容易得到很多这方面问题，具体详见：HBASE-13488HDFS-1836等等。基于当前的HDFS和HBase版本，针对这个问题暂时没有好的解决方案，只能通过定期重启来避免宕机，好在HBase也提供了平滑重启一个RegionServer的命令graceful_stop，执行这个重启命令不会对上层业务有任何影响，具体执行过程如下：
RegionServer宕机总结
RegionServer宕机是HBase系统不可完全避免的场景，本文分三个部分从运维角度介绍RegionServer宕机这一事件。首先介绍宕机对应用方会造成什么影响、数据会不会丢等，第二部分接着介绍一旦RegionServer宕机之后应该如何正确地处理，第三部分使用一个具体事例介绍如何通过排查日志以及监控定位RegionServer宕机原因并设法避免宕机发生。看官阅览之后如果能对HBase中RegionServer宕机有一个基础的了解，俺心甚慰！