ZooKeeper 在 HBase 集群中扮演了什么角色？

在 HBase 集群中，ZooKeeper (ZK) 扮演着“中央协调者”和“集群神经中枢”的角色。HBase 作为一个高度分布式的 NoSQL 数据库，极其依赖 ZooKeeper 来维持集群的稳定状态、实现高可用性以及路由客户端请求。

没有 ZooKeeper，分布式的 HBase 集群将无法运行。

具体来说，ZooKeeper 在 HBase 中主要承担以下几个核心功能：

Active/Standby 模式：生产环境中通常会有多个 HMaster 节点。ZooKeeper 负责在这些节点中选举出一个作为 Active HMaster（主节点），其他的作为 Backup/Standby HMaster（备用节点）。
故障转移（Failover）：HMaster 启动时会在 ZK 中创建一个临时节点（Ephemeral Node，例如 /hbase/master）。备用 Master 会通过 ZK 的 Watcher 机制监听这个节点。如果 Active HMaster 宕机，该临时节点会自动消失，备用 Master 收到通知后会立刻发起新一轮选举，接管集群，从而实现高可用。

路由寻址的第一步：HBase 中有一张特殊的系统表叫 hbase:meta，它记录了集群中所有用户表数据（Region）的分布情况（即哪个 Region 在哪个 RegionServer 上）。
ZK 的作用：hbase:meta 表本身存在于哪个 RegionServer 上？这个极其重要的位置信息是硬编码保存在 ZooKeeper 中的（路径通常是 /hbase/meta-region-server）。
客户端直连：当 HBase 客户端需要读写数据时，它首先会连接 ZooKeeper 获取 hbase:meta 表的位置，然后再去对应的 RegionServer 查找真正的用户数据。这意味着，客户端读写数据完全不需要经过 HMaster，减轻了 Master 的压力。

心跳与临时节点：每个 RegionServer 启动时，都会在 ZK 的 /hbase/rs 目录下创建一个以自己名字命名的临时节点。RegionServer 运行期间会与 ZK 保持会话（心跳）。
宕机感知：HMaster 会监听 /hbase/rs 这个目录。如果某个 RegionServer 宕机或网络中断，它与 ZK 的心话超时，ZK 上的临时节点就会被自动删除。
触发恢复：HMaster 收到 ZK 的节点删除通知后，就会立刻知道该 RegionServer 挂了，随之启动故障恢复流程（例如：分割该 RS 的 WAL 日志，并将其负责的 Regions 重新分配给其他健康的 RegionServer）。

Region 状态转换（Region In Transition, RIT）：当 Region 进行拆分（Split）、合并（Merge）或负载均衡移动时，状态是非常复杂的。HBase 利用 ZK 来协调这些状态转换，防止多个组件同时对同一个 Region 进行操作导致数据不一致（提供分布式锁的功能）。
集群配置与元数据：ZK 存储了 HBase 集群的一些全局信息，例如表 Schema 的操作状态、ACL（访问控制列表）权限信息、以及集群当前的运行状态（/hbase/running）等。

为了更好理解 ZK 的作用，我们可以看看客户端是如何读取一行数据的：

Client -> ZooKeeper：客户端首先连接 ZK，读取 /hbase/meta-region-server 节点，得知 hbase:meta 表在 RegionServer A 上。
Client -> RegionServer A：客户端连接 RS A，查询 hbase:meta 表，得知自己想要读的用户数据（例如 UserTable 的 rowkey1）在 RegionServer B 上。
Client -> RegionServer B：客户端直接连接 RS B，完成最终的数据读取。（注：客户端会将寻址结果缓存起来，下次读写相同的 Region 就不用再走前两步了）。

一句话概括：
ZooKeeper 就像是 HBase 集群的人事部（监控员工/RS存活）、董事会（选举CEO/HMaster）以及公司前台指引（告诉Client数据在哪里）。

播面