HBase 核心架构解析：HMaster、RegionServer 与 ZooKeeper 协同机制

2.4 ZooKeeper：集群的"协调者"

ZooKeeper在 HBase 中扮演着至关重要的协调角色，它存储了集群的关键状态信息。

ZooKeeper 中存储的关键信息：

/hbase
├── /meta-region-server   # meta 表所在的 RegionServer
├── /master               # Active HMaster 地址
├── /backup-masters       # Standby HMaster 列表
├── /region-in-transition # 正在迁移的 Region
└── /rs                   # 所有 RegionServer 列表
    ├── /rs1
    ├── /rs2
    └── /rs3

三、HBase 的数据存储单元：Region

3.1 Region 是什么？

Region是 HBase 表数据分布的基本单位。一个 HBase 表根据 RowKey 的范围被分成多个 Region，每个 Region 包含这个区域内所有数据。例如，User 表可能按用户 ID 范围划分为 Region1 (001-100)、Region2 (101-200) 等。

3.2 Region 的内部结构

每个 Region 内部包含了 RowKey 范围、列族映射以及对应的 Store 和 WAL。

// 每个 Region 包含的内容示意
class Region {
    // 1. RowKey 范围
    String startKey;
    String endKey;
    
    // 2. 包含的列族 Map<ColumnFamily, Store> stores;
    
    // 3. 每个 Store 对应一个列族
    class Store {
        MemStore memStore;      // 内存缓存
        List<StoreFile> storeFiles; // 磁盘文件
    }
    
    // 4. WAL 预写日志
    WAL wal;
}

3.3 Region 的分配与迁移

当客户端创建表时，HMaster 会决定 Region 数量并分配给不同的 RegionServer。ZooKeeper 会记录这些位置信息，以便客户端快速定位。

四、HBase 的读写流程

4.1 读数据流程

读操作的流程相对清晰，核心在于通过 ZooKeeper 找到目标 Region 的位置。

读流程要点：

1. 客户端先从 ZooKeeper 获取 hbase:meta 表的位置。
2. 从 meta 表查询目标 RowKey 所在的 Region 和 RegionServer。
3. 直接连接目标 RegionServer 读取数据。
4. 读数据时，先查 MemStore（内存），再查 StoreFile（磁盘）。

4.2 写数据流程

写操作为了保证数据不丢失，采用了 WAL + MemStore 的机制。

写流程要点：

1. 先写 WAL（顺序写，保证数据不丢）。
2. 再写 MemStore（内存，提升写入性能）。
3. 返回客户端成功。
4. 异步将 MemStore 刷写到 HDFS 成为 StoreFile。

五、HBase 的关键机制

5.1 Region 分裂

随着数据增长，Region 会不断变大，当达到阈值时触发分裂。这有助于实现负载均衡。

分裂触发条件：

• 单个 Region 的 StoreFile 大小超过 hbase.hregion.max.filesize（默认 10GB）。
• 由 RegionServer 自行决定，不需要 HMaster 参与。

5.2 负载均衡

HMaster 会定期执行负载均衡策略，将过载 RegionServer 上的 Region 迁移到低负载节点。

// HMaster 定期执行负载均衡逻辑示意
public void balance() {
    // 1. 获取所有 RegionServer 的负载
    Map<RegionServer, Integer> loads = getRegionServerLoads();
    
    // 2. 计算平均负载
    double avgLoad = calculateAverage(loads);
    
    // 3. 找出过载和低载的 RegionServer
    List<RegionServer> overloaded = findOverloaded(loads, avgLoad);
    List<RegionServer> underloaded = findUnderloaded(loads, avgLoad);
    
    // 4. 将过载 RS 的 Region 迁移到低载 RS
    for (RegionServer from : overloaded) {
        for (RegionServer to : underloaded) {
            moveRegion(from, to);
        }
    }
}

5.3 故障恢复

当 RegionServer 宕机时，系统会自动触发恢复流程：

1. ZooKeeper 检测到心跳超时。
2. HMaster 启动故障恢复流程。
3. 将宕机 RS 的 WAL 进行分割。
4. 将其管理的 Region 重新分配到其他 RS。
5. 其他 RS 从 WAL 恢复数据。

六、架构设计亮点

6.1 无单点故障设计

6.2 读写分离设计

• 写路径：Client → RegionServer → WAL → MemStore → HFile
• 读路径：Client → RegionServer → MemStore/BlockCache → HFile

6.3 数据本地性

HBase 充分利用数据本地性。当 Region 在某个 RegionServer 上时，它会优先读取本地的 HDFS 数据。如果 Region 迁移了，新的 RegionServer 可能需要远程读数据，通过 Compaction 机制可以逐步将数据转为本地。

七、面试高频问题

Q1：HBase 有哪些核心组件？各有什么作用？ 答：三大核心组件：HMaster（管理元数据、DDL、负载均衡）、RegionServer（处理读写、管理 Region）、ZooKeeper（集群协调、状态监控、元数据入口）。

Q2：RegionServer 宕机后会发生什么？ 答：ZooKeeper 检测心跳超时，HMaster 启动恢复流程，分割 WAL，重新分配 Region，其他 RS 从 WAL 恢复数据。

Q3：HBase 的读写流程是怎样的？ 答：读流程：ZK → meta 表 → 目标 RS → 先读 MemStore → 再读 StoreFile；写流程：ZK → meta 表 → 目标 RS → 写 WAL → 写 MemStore → 返回成功。

Q4：HMaster 的高可用是如何实现的？ 答：通过 ZooKeeper 协调 Active-Standby 模式，多个实例只有一个 Active，ZK 记录 Active 地址，宕机时 Standby 选举接管。

Q5：Region 是什么？如何分布？ 答：Region 是 HBase 表数据分布的基本单位，根据 RowKey 范围划分。分布在不同的 RegionServer 上，实现负载均衡和水平扩展。

八、总结

8.1 架构核心要点

• HMaster：元数据管理、负载均衡、故障恢复。
• RegionServer：数据读写、Region 管理、MemStore/StoreFile。
• ZooKeeper：集群协调、状态监控、元数据入口。

8.2 数据流向

写：Client → RegionServer → WAL → MemStore → HFile 读：Client → RegionServer → MemStore/BlockCache → HFile

8.3 一句话总结

HBase 通过 HMaster 管控、RegionServer 执行、ZooKeeper 协调的三驾马车，构建了一个高可用、可扩展的分布式 KV 数据库。

掌握了 HBase 的架构，你就掌握了理解其所有行为的基础，无论是性能调优、问题排查还是二次开发，都能得心应手！