HBase 与 ZooKeeper 的关系

Hbase 与 zookeeper 的关系

HBase 主要用 ZooKeeper 来实现 HA 选举与主备集群主节点的切换、系统容错、meta-region 管理、Region 状态管理和分布式 SplitWAL 任务管理等。

RegionServer 管理

HBase 集群启动时，每台 RegionServer 在 Zookeeper 中 /hbase/rs 注册一个自己的临时节点，HMaster 会利用这些临时节点来发现可用的 RegionServer，还可以利用临时节点来跟踪及其故障和网络分区。这些临时节点相当于一个“会话”，会话是客户端链接上Zookeeper服务器之后自动生成的。每个会话有一个唯一的 id，RegionServer 会用这个 id 不断向 Zookeeper 服务器发送“心跳”，一旦 RegionServer 发生故障，发送心跳则会停止，当超过限定时间后，Zookeeper 服务器会判定会话超时，并自动删除属于它的临时会话。与此同时，HMaster 则会接收到 ZooKeeper 的 NodeDelete 通知，从而感知到某个节点断开，并立即开始容错工作。

meta-region 管理

每次客户端向 HBase 发起请求时，都会去查询 meta-region，默认目录是：/hbase/meta-region-server，如果发生 region 的迁移，zookeeper 都会进行更新，以便其他客户端请求时，总能查到最新的 meta-region 信息。

Region 管理

Region 的状态经常会发生变更，比如 Region 迁移、上线、离线，在 Hbase 2.x 之前都是通过 zookeeper 来统一管理的。

预写日志恢复

RegionServer 经常会通过 WAL 预写日志进行数据的恢复，由于 RegionServer 数据量比较大，单个节点进行恢复速度比较慢，HMaster 会把 WAL 预写日志进行切分，放到 Zookeeper 的 /hbase/splitWAL 目录中，让其他的 RegionSever 都能参与日志的恢复工作，提升恢复速度。ZooKeeper 在这里担负起了分布式集群中相互通知和信息持久化的角色。

HBase 中 ZooKeeper 的核心配置

一个分布式 HBase 集群的部署运行强烈依赖于 ZooKeeper，在当前的 HBase 系统实现中，ZooKeeper 扮演了非常重要的角色。在配置文件 conf/hbase-site.xml 中配置与 ZooKeeper 相关的几个重要配置项：

• hbase.zookeeper.quorum：默认为 localhost，必须进行配置。ZooKeeper 集群的地址。
• hbase.zookeeper.property.clientPort：默认为2181，可以不进行配置。
• zookeeper.znode.parent：默认为 /hbase，可以不配置。HBase 在 ZooKeeper 的 zNode 根节点位置，每次 HBase 集群重启 zNode 都会重建，所以如果集群重启的话，重启之前直接删除该 zNode 也是没有问题的。
• zookeeper.session.timeout：表示 RegionServer 与 ZooKeeper 之间的会话超时时间，一旦 session 超时，ZooKeeper 就会感知到，通知 Master 将对应的 RegionServer 移出集群，并将该 RegionServer 上所有 Region 迁移到集群中其他RegionServer。

HBase 集群启动之后，使用客户端进行读写操作时也需要配置上述 ZooKeeper 相关参数。

HBase 在 ZooKeeper 中的目录结构

meta-region-server：存储 HBase 集群 hbase:meta 元数据表所在的 RegionServer 访问地址。客户端读写数据首先会从此节点读取 hbase:meta 元数据的访问地址，将部分元数据加载到本地，根据元数据进行数据路由。

rs：集群中所有运行（在线）的 RegionServer 的临时节点。详见上述 RegionServer 管理章节。

master 和 backup-masters：
通常来说生产线环境要求所有组件节点都避免单点服务，HBase 使用 ZooKeeper 的相关特性实现了 Master 的高可用功能。其中master 节点是集群中对外服务的管理服务器，backup-masters 下的子节点是集群中的备份节点，一旦对外服务的主 Master 节点发生了异常，备 Master 节点可以通过选举切换成主 Master，继续对外服务。需要注意的是备 Master 节点可以有多个。

namespace：集群中所有的名称空间

table：集群中所有表信息。

table-lock：HBase 系统使用 ZooKeeper 相关机制实现分布式锁。HBase 中一张表的数据会以 Region 的形式存在于多个 RegionServer 上，因此对一张表的 DDL 操作（创建、删除、更新等操作）通常都是典型的分布式操作。每次执行 DDL 操作之前都需要首先获取相应表的表锁，防止多个 DDL 操作之间出现冲突，这个表锁就是分布式锁。

online-snapshot：用来实现在线 snapshot 操作。表级别在线 snapshot 同样是一个分布式操作，需要对目标表的每个 Region 都执行 snapshot，全部成功之后才能返回成功。Master 作为控制节点给各个相关 RegionServer 下达 snapshot 命令，对应 RegionServer 对目标 Region 执行 snapshot，成功后通知 Master。Master 下达 snapshot 命令、RegionServer 反馈 snapshot 结果都是通过 ZooKeeper 完成的。

splitWAL： 在RegionServer宕机恢复时，用于存放待切分的WAL日志路径。详见RegionServer 宕机恢复流程(DSL)。

hbaseid：集中唯一的 ID。

region-in-transition：（该路径在 2.x 版本中已经去掉）在当前 HBase 系统实现中，迁移 Region 是一个非常复杂的过程。首先对这个 Region 执行 unassign 操作，将此 Region 从 open 状态变为 offline 状态（中间涉及 PENDING_CLOSE、CLOSING 以及CLOSED 等过渡状态），再在目标 RegionServer 上执行 assign 操作，将此 Region 从 offline 状态变成 open 状态。这个过程需要在 Master 上记录此 Region 的各个状态。目前，RegionServer 将这些状态通知给 Master 是通过 ZooKeeper 实现的，一旦 Region 发生 unssign 操作，就会在这个节点下生成一个子节点，子节点的内容是“事件”经过序列化的字符串，并且 Master 会在这个子节点上监听，一旦发生任何事件，Master 会监听到并更新 Region 的状态。RegionServer 会在 region-in-transition 中变更 Region 的状态，Master 监听 ZooKeeper 对应节点，以便在 Region 状态发生变更之后立马获得通知，得到通知后 Master 再去更新 Region 在 hbase:meta 中的状态和在内存中的状态。

replication：（该路径在2.X版本中已经去掉）用来实现HBase复制功能。

recovering-regions：（该路径在2.X版本中已经去掉）
用来实现 HBase 分布式故障恢复。为了加速集群故障恢复，HBase实现了分布式故障恢复，让集群中所有RegionServer都参与未回放日志切分。ZooKeeper是Master和RegionServer之间的协调节点。