【分布式数据库】HBase中Zookeeper核心配置信息解读

目录一、HBase与Zookeeper的关系1.1 HA管理1.2 RegionServer管理1.3 元数据Region1.4 Region管理1.5 预写日志恢复1.6 hbase-site.xml中zookeeper的配置集群的主节点的选举和主备的切换跟Hadoop中Namnode的HA的选举和切换机制类似（后面我会专门写一篇文章讲解Namenode的HA）。为啥子选择zookeeper干这

开着拖拉机回家

8981人浏览 · 2021-12-14 22:30:14

开着拖拉机回家 · 2021-12-14 22:30:14 发布

1.6 hbase-site.xml中zookeeper的配置

一、HBase与Zookeeper的关系

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

1.1 HA管理

集群的主节点的选举和主备的切换跟Hadoop中Namnode的HA的选举和切换机制类似（后面我会专门写一篇文章讲解Namenode的HA）。

1.2 RegionServer管理

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

为啥子选择zookeeper干这个事？因为随着集群节点越来越多，HMaster的管理负担会越来越重，另外它自身也有挂掉的可能，因此数据还需要持久化，zookeeper通常是一个集群，这样稳定性相对就高了很多。

1.3 元数据Region

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

1.4 Region管理

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

1.5 预写日志恢复

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

1.6 hbase-site.xml中zookeeper的配置

<property>
  <name>hbase.zookeeper.property.clientPort</name>
  <value>2181</value>
</property>

<property>
  <name>hbase.zookeeper.quorum</name>
  <value>hdp101,hdp102,hdp103</value>
</property>

<property>
  <name>hbase.zookeeper.useMulti</name>
  <value>true</value>
</property>
<property>
  <name>zookeeper.recovery.retry</name>
  <value>6</value>
</property>

<property>
  <name>zookeeper.session.timeout</name>
  <value>90000</value>
</property>
  
<property>
      <name>zookeeper.znode.parent</name>
      <value>/hbase-unsecure</value>
 </property>

其中，hbase.zookeeper.quorum 为Zookeeper 集群的地址，必须进行配置，默认的端口为2181，可以不进行配置，zookeeper.znode.parent 为 /hbase-unsecure。在Hbase集群启动后，使用客户端进行读写操作，需要配置上面相关的参数。

其次，zookeeper.session.timeout 也是一个重要的参数，表示RegionServer 与zookeeper 之间的会话时间，一旦会话超时，Zookeeper 就会感知到，通知HMaster将对应的RegionServer移除集群，并将给RegionServer上所有Region移动到其他的RegionServer上。

HBase在zookeeper根节点上创建的子节点：

[zk: localhost:2181(CONNECTED) 1] get /hbase-unsecure

cZxid = 0x100000026      // 每个znode被赋予一个全局唯一的ID，我们称之为zxid
ctime = Sat May 22 16:09:29 CST 2021 //znode创建时间
mZxid = 0x100000026
mtime = Sat May 22 16:09:29 CST 2021  //znode最后一次修改时间
pZxid = 0x4a0000003b  // 最后一次修改该znode子节点的 zxid
cversion = 38     // 该节点子节点的版本
dataVersion = 0     // 该节点内容的版本，每次修改内容，版本都会增加
aclVersion = 0      // 该节点的 ACL 版本
ephemeralOwner = 0x0  // 如果该节点是临时节点（ephemeral node），会列出该节点所在客户端的 session id；如果不是临时节点，该值为 0
dataLength = 0      // 该节点存储的数据长度
numChildren = 16    // 该节点子节点的个数

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

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

table：集群中所有表信息

region-in-transtion：在当前的Hbase系统中，迁移region是一个非常复杂的过程。首先对这个Region 执行unassign操作，将此Region 从open状态变为offline 状态，再在目标 RegionServer上执行assigi操作，将此Region从offline状态变成open状态，这个过程需要在master上记录region的各个状态。目前RegionServer 将这些状态通知给Master是通过zookeeper 实现的，RegionServer会在region-in-transition中变更Region的状态，Master 监听zookeeper 对应节点，以便在Region状态发生变更之后及时获得通知，得到通知后Master再去更新Region在 hbase:meta 中状态和在内存中的状态。

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

online-snapshot：用来实现在线snapshot操作。表级别在线 snapshot同样是一个分布式操作，需要对多个目标表的每个Region都执行 snapshot，全部成功后才返回成功。