播面

在 HBase 架构中，HMaster 主要负责集群的管理工作（如元数据管理、负载均衡、Region 分配、DDL 操作等），而不直接参与客户端的数据读写（DML 操作）。

因此，HMaster 宕机后的影响以及 HBase 的高可用机制（HA）是非常经典的架构设计问题。以下是详细解答：

---

一、 当 HMaster 宕机后，会发生什么？

即使 HMaster 宕机，HBase 集群并不会立即瘫痪，短时间内对数据读写几乎没有影响，但长期来看会导致集群管理功能丧失。具体表现如下：

1. 不受影响的操作（客户端依然可以读写数据）

• 数据读写（Put/Get/Scan）正常进行：HBase 客户端在读写数据时，是直接与 ZooKeeper 交互获取 hbase:meta 表的位置，然后直接与对应的 RegionServer 进行通信。整个数据读写链路完全不需要 HMaster 的参与。
• 只要 RegionServer 不宕机，现有的表和数据都可以正常对外提供读写服务。

2. 受影响的操作（集群管理功能瘫痪）

一旦 HMaster 宕机且没有备用节点接管，以下功能将无法使用：

• DDL 操作失败：无法创建（Create）、删除（Drop）、修改（Alter）表，也无法禁用（Disable）或启用（Enable）表。
• Region 分配与负载均衡停止：HMaster 负责监控各个 RegionServer 的负载并进行 Region 迁移。HMaster 宕机后，集群无法进行负载均衡。
• RegionServer 故障无法恢复（最致命）：如果此时某台 RegionServer 宕机，该节点上的 Region 将变成孤儿。因为没有 HMaster 来重新分配这些 Region 和触发 WAL 的拆分恢复，这部分数据将彻底变得不可用，直到 HMaster 恢复。
• Region Split/Merge 流程受阻：虽然 Region 的分裂主要由 RegionServer 执行，但需要 HMaster 来感知并更新状态。HMaster 缺失可能导致分裂后的子 Region 无法被正确分配。

---

二、 HBase 如何保证 HMaster 的高可用（Active-Standby 切换）？

为了解决单点故障问题，HBase 强依赖 ZooKeeper (ZK) 来实现 HMaster 的高可用（HA），采用的是 Active-Standby（一主多备） 架构。

具体切换流程和原理如下：

1. 启动与选主阶段（竞争 Active）

• 在一个 HBase 集群中，可以启动多个 HMaster 进程。
• 当这些 HMaster 启动时，它们都会尝试连接 ZooKeeper，并在 ZK 上创建一个临时节点（Ephemeral Node），路径通常是 /hbase/master。
• ZooKeeper 保证了全局的强一致性：只有一个 HMaster 能够成功创建该节点。创建成功的 HMaster 就成为 Active HMaster（主节点）。
• 创建失败的其他 HMaster 会捕获到 NodeExists 异常，它们自动转为 Standby HMaster（备用节点）。同时，它们会在 ZK 中注册一个针对 /hbase/master 节点的 Watcher（监听器），并在 /hbase/backup-masters/ 目录下注册自己的信息。

2. 正常运行阶段（监控心跳）

• Active HMaster 会与 ZK 保持 Session 会话（发送心跳）。
• 只要 Active HMaster 存活，/hbase/master 这个临时节点就会一直存在。
• Standby HMaster 处于休眠等待状态，只做一件事：监听（Watch）该临时节点的状态。

3. 故障检测与触发切换（Active 宕机）

• 如果 Active HMaster 发生宕机、进程被杀或者网络隔离，它与 ZK 的 Session 将会超时断开。
• Session 断开后，ZooKeeper 会自动删除 /hbase/master 这个临时节点。

4. 重新选举与接管阶段（Standby 升级为 Active）

• 临时节点被删除后，ZK 会立刻通过 Watcher 机制通知所有处于监听状态的 Standby HMaster。
• 所有的 Standby HMaster 收到通知后，会被唤醒，并再次发生“抢占”——重新尝试在 ZK 上创建 /hbase/master 临时节点。
• 同样，只有一个 Standby HMaster 能创建成功，它将升级为新的 Active HMaster。

5. 新 Active HMaster 的恢复工作

新 HMaster 走马上任后，不能立刻提供完整的管理服务，它需要先“了解局势”（状态恢复）：

1. 读取元数据：从 ZK 获取当前集群的状态、RegionServer 的存活列表等。
2. 处理遗留问题：检查是否有在上一任 HMaster 宕机期间死掉的 RegionServer。如果有，新 HMaster 会立刻启动故障恢复流程（切分 WAL 日志，重新分配故障节点上的 Region）。
3. 接管完成：状态恢复完毕后，新 HMaster 开始正常提供 DDL、负载均衡等服务。

总结

HBase 的架构设计非常巧妙地实现了控制流（HMaster）与数据流（RegionServer）的分离。HMaster 宕机不会导致读写立刻中断。而依靠 ZooKeeper 的临时节点和 Watcher 机制，HBase 能够实现毫秒级/秒级的故障感知，并在多个 HMaster 之间实现无缝的 Active-Standby 自动切换，从而保证了集群的高可用性。