HBase组件内部通讯机制分析

最近线上遇到这样一个问题，在创建一个新表时，一台RegionServer突然宕机，RegionServer错误日志显示如下：

Master错误日志如下：

最终排查发现是运维同学当晚有变更，修改了宕机RegionServer服务器的hosts文件，删除了HBase集群中其他机器的域名配置信息；我们都知道访问HBase集群需要用域名的形式，HBase各个组件内部也是通过域名的形式通讯的，修改了hosts后应该马上就会宕机才是；但实际上从修改hosts到RegionServer宕机之间有好几个小时，RegionServer一直都稳定运行，直到创建新表时才出现问题，这又怎么解释呢？

带着上述疑问，我们先一起回顾一下HBase集群的基础组件与客户端简单的流程。

1. 客户端调用ZooKeeper查询meta表在哪个RegionServer；

2. 客户端去meta表所在RegionServer查询当前rowkey再哪个Region，由哪个RegionServer管理；

3. 客户端直接通过RPC请求读写数据所在RegionServer；

4. 客户端会缓存meta的查询结果，后续不需要再进行1-2步骤；

1. HMaster启动时，会试图去ZooKeeper注册一个临时节点并添加监听，如果注册成功，则当前HMaster成为active，如果失败则说明已经存在active HMaster，当前HMaster成为standby；active HMaster宕机后，关联的Zookeeper中的临时节点会被删除，standby HMaster监听到后会将自己提升为新的active HMaster；

2. RegionServer启动时，也会去ZooKeeper注册一个临时节点，HMaster会监控所有RegionServer的临时节点，当有节点删除时，HMaster会停止对应的RegionServer；

3. RegionServer启动时会向HMaster报告当前启动的时间、状态、hostname等信息；

4. 这里为了简单，HDFS直接用一个图表示，实际生产中，都会部署一个RegionServer与一个DataNode是在同一台机器，保持数据本地性。

集群管理操作指Region分配、负载均衡、故障恢复等相关操作，这里通过create table语句来举例说明：

1. HMaster收到create table语句，调用meta表所在RegionServer，更新新表region的meta信息；

2. HMaster将新表的Region（预分区则有多个region）分配到RegionServer上；

3. 各个RegionServer负责打开分配到自己的Region；

4. 打开Region最后一步需要调用meta表所在RegionServer更新region的meta信息，最终才能上线Region；

5. 上述过程HMaster跟RegionServer都需要通过ZooKeeper的交互来协调完成上述工作（主要是region-in-tansition节点）；

6. HMaster调用HDFS创建好表对应的文件目录结构（为了简单，图中没体现）。

根据上面的分析，得出HBase集群内部协作机制如下：

1. HMaster、RegionServer与ZooKeeper之间为长连接，主要作用为通过ZooKeeper来协调完成集群层面的操作与保持心跳；

2. RegionServer之间有一定的通信，主要提现为调用meta表所在的RegionServer去更新region的meta信息；

3. HMaster会下发指令到RegionServer执行，例如：shutdown、分配Region、Flush等操作；

4. RegionServer也会向HMaster汇报启动，关闭等状态信息。