目录
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，全部成功后才返回成功。
replication：用来实现HBase复制功能。
splitWal：用来实现Hbase分布式故障恢复。为了加速加速集群故障恢复，HBase实现分布式故障恢复，让集群中所有RegionServer 都参与未回放日志切分。Zookeeper是Master和RegionServer之间的协调节点。
rs：集群中所有运行的RegionServer
flush-table-proc: flush进程
namespace: HBase默认的命名空间
