3. HBase架构原理：HMaster、RegionServer、ZooKeeper的角色与协作机制
好，咱们今天聊聊HBase的架构。说实话，很多初学者一上来就被HMaster、RegionServer、ZooKeeper这几个角色搞晕了。我当年刚接触HBase时也一样，觉得它们之间关系挺绕的。其实说白了，这三兄弟各司其职，配合得相当默契。
你想想看，一个分布式系统要稳定运行，至少得解决三个问题：谁来管事儿？谁来干活儿？谁来协调？HBase的答案就是：HMaster管事儿，RegionServer干活儿，ZooKeeper协调。嗯，就这么简单。
3.1 ZooKeeper：集群的“定海神针”
先说说ZooKeeper。我个人习惯把ZooKeeper比作HBase集群的“大脑中枢”。没有它，整个集群就是一团散沙。
ZooKeeper的核心职责：
- 元数据存储：保存HBase的元数据信息，比如哪些RegionServer活着，哪些Region在哪个Server上
- 选主机制：负责选举HMaster，保证任何时候只有一个Active Master
- 状态同步：实时监控RegionServer的心跳，一旦发现节点挂了，立刻通知HMaster
- 分布式锁：提供分布式协调服务，比如表创建、删除时的互斥操作
我在项目中遇到过一个问题：某次集群扩容后，新加的RegionServer一直注册不上。查了半天，发现是ZooKeeper的会话超时时间设置得太短了。新节点还没来得及完成初始化，就被ZooKeeper踢出去了。后来我把zookeeper.session.timeout从30秒调到了60秒，问题就解决了。
避坑指南：我曾经因为ZooKeeper集群和HBase集群部署在同一批机器上，导致资源争抢严重。建议ZooKeeper独立部署，至少3台机器，奇数节点。别问我为什么是奇数，你想想看，选举投票要过半数，偶数节点万一平局怎么办？
3.2 HMaster：集群的“大管家”
HMaster是干什么的？说白了就是管全局的。但它不直接处理数据读写请求，这点很重要。
HMaster的主要工作：
- 表管理：创建、删除、修改表结构（DDL操作）
- Region分配：决定Region应该分配到哪个RegionServer上
- 负载均衡：定期检查各RegionServer的负载，做Region迁移
- 故障恢复：当RegionServer宕机时，负责将其上的Region重新分配给其他节点
你可能会问：那HMaster挂了怎么办？别慌，HBase支持HMaster的高可用。ZooKeeper会实时监控HMaster的状态，一旦Active Master挂了，Backup Master会立刻顶上。这个过程对客户端是透明的，读写操作完全不受影响。
注意：HMaster的故障切换虽然快，但期间DDL操作（比如建表、删表）会暂时不可用。所以生产环境中，我建议把DDL操作放在业务低峰期执行。
3.3 RegionServer：真正的“搬砖工”
好了，前面说的都是“管事儿”的，现在聊聊真正“干活儿”的——RegionServer。
RegionServer是HBase的数据节点，每个RegionServer管理若干个Region。Region是什么？你可以把它理解成HBase表的一个数据分片。一张大表会被水平切分成多个Region，分散到不同的RegionServer上。
RegionServer的内部结构：
- WAL（Write-Ahead Log）：预写日志，所有写操作先写WAL，再写MemStore。防止数据丢失
- BlockCache：读缓存，缓存最近访问的数据块
- MemStore：写缓存，数据先写到内存，满了再刷到磁盘
- HFile：磁盘上的数据文件，数据最终持久化到这里
我记得有一次线上事故，某个RegionServer的MemStore一直不刷盘，导致内存爆了。后来发现是HBase的刷盘策略配置有问题。默认的hbase.hregion.memstore.flush.size是128MB，但当时业务写入量太大，还没来得及刷盘就满了。我调整了hbase.regionserver.global.memstore.size，限制了全局MemStore的使用比例，才稳住局面。
3.4 三者的协作机制
现在咱们把这三个角色串起来，看看它们是怎么配合的。
一次完整的读写请求流程：
- 客户端先访问ZooKeeper，获取元数据表（hbase:meta）所在的RegionServer地址
- 客户端再去那个RegionServer上查询目标Region的位置
- 客户端直接连接目标RegionServer，发起读写请求
- RegionServer处理请求，返回结果
你看，整个过程HMaster完全不参与。这就是HBase设计的高明之处——读写路径上不经过Master，避免了单点瓶颈。
协作机制总结：
| 角色 | 核心职责 | 故障影响 |
|---|---|---|
| ZooKeeper | 协调、选主、状态监控 | 集群不可用 |
| HMaster | DDL操作、负载均衡、故障恢复 | DDL不可用，读写正常 |
| RegionServer | 数据读写、Region管理 | 该节点上的数据不可用 |
嗯，这里要注意一点：RegionServer宕机后，HMaster会检测到，然后把它上面的Region重新分配到其他节点。这个过程需要重放WAL日志，所以会有短暂的不可用。我曾经遇到过RegionServer宕机后，WAL日志损坏导致数据丢失的情况。从那以后，我养成了一个习惯——定期检查WAL的完整性，并且把hbase.regionserver.hlog.splitlog.writer.threads调大一些，加快日志恢复速度。
3.5 实战中的架构考量
最后，分享几个我在实际项目中总结的经验：
- ZooKeeper集群：至少3台，独立部署，不要和HBase混部。磁盘用SSD，因为ZooKeeper对IO延迟很敏感
- HMaster：配置2-3台做高可用，但不要太多。Master之间需要同步状态，太多了反而增加开销
- RegionServer：根据业务量动态调整。我一般建议每台机器管理100-200个Region，太多会导致GC压力大
- 网络：RegionServer之间的网络延迟要低，因为Region迁移、日志恢复都需要网络传输
你想想看，HBase这套架构设计其实挺巧妙的。它把“管理”和“计算”分离，HMaster只负责元数据和调度，RegionServer专注数据读写。再加上ZooKeeper这个“协调员”，整个集群就能稳定高效地运转了。
好了，这一章就到这里。下一章咱们聊聊HBase的数据模型和表设计，那可是实战中的重头戏。