平武建站

HBase依赖Zookeeper原因分析

本篇内容介绍了“HBase依赖Zookeeper原因分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

目前创新互联建站已为上千家的企业提供了网站建设、域名、雅安服务器托管、网站托管、服务器托管、企业网站设计、大连网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

一、ZooKeeper相关知识：

概念：

  Zookeeper是一个分布式应用程序协调服务，提供了简单易用的接口和性能高效、功能稳定的系统让用户可以很轻松解决分布式应用程序下面的出现的协调服务，确保避免出现竞态条件或者死锁等错误。其设计目标是减轻分布式应用从零开始实现分布式协调服务的压力。

    假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，现在把这些配置全部放到zookeeper上去，保存在 zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 zookeeper 的通知，然后从 zookeeper 获取新的配置信息应用到系统中。

数据节点(znode)：

    Zookeeper维护一个类似文件系统的数据结构，每一个节点是指数据模型中的数据单元，称为ZNode。ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个ZNode，如/hbase-unsecure/replication,其中hbase-unsecure和replication都是ZNode。每个ZNode上都会保存自己的数据内容，同时会保存一系列属性信息。每个znode由三部分组成。

  • stat：状态信息，描述该znode的版本，权限等信息

  • data：与该znode关联的数据

  • children：该znode下的子节点

zkCli.sh使用：

    ZooKeeper提供了一个交互式shell，允许各种Znode操作，就像在典型的文件系统中一样。还可以使用get命令获得关于znode内容的一些信息。

两种方式：

#hbase命令直接登录[hbase@salver158 ~]$ hbase zkcli
#zookeeper客户端脚本登录[hbase@salver158 ~]$ /usr/hdp/2.6.3.0-235/zookeeper/bin/zkCli.sh -server salver158.hadoop.unicom:2181

    zkCli客户端中输入 help 命令（其实输入任何 zkCli 不能识别的命令，都会列出所有的命令），查看可用的命令：

[zk: salver158.hadoop.unicom:2181(CONNECTED) 0] helpZooKeeper -server host:port cmd args  stat path [watch]  set path data [version]  ls path [watch]  delquota [-n|-b] path  ls2 path [watch]  setAcl path acl  setquota -n|-b val path  history   redo cmdno  printwatches on|off  delete path [version]  sync path  listquota path  rmr path  get path [watch]  create [-s] [-e] path data acl  addauth scheme auth  quit   getAcl path  close   connect host:port

有几个比较重要的命令我这里结合HBase的znode简单说一下，其他命令请自行百度：

  1. create：在树中的某个位置创建一个节点。

  2. delete：删除一个节点。

  3. exists：测试一个节点是否存在。

  4. get data：读取节点数据。

  5. set data：向节点中写入数据。

  6. get children：检索某节点的子节点列表。

  7. sync：等待要传播的数据。

这里专门说下get path 获取节点信息

[zk: salver158.hadoop.unicom:2181(CONNECTED) 3] get /hbase-unsecure cZxid = 0x1a005eda9b   //每个znode被赋予一个全局唯一的ID，我们称之为zxidctime = Thu Aug 15 14:46:01 CST 2019 //znode创建时间mZxid = 0x1a005eda9b      //mtime = Thu Aug 15 14:46:01 CST 2019 //znode最后一次修改时间pZxid = 0x2100398049  //最后一次修改该znode子节点的 zxidcversion = 89   //该节点子节点的版本dataVersion = 0 //该节点内容的版本，每次修改内容，版本都会增加aclVersion = 0  //该节点的 ACL 版本ephemeralOwner = 0x0  //如果该节点是临时节点（ephemeral node），会列出该节点所在客户端的 session id；如果不是临时节点，该值为 0dataLength = 0  //该节点存储的数据长度numChildren = 17  //该节点子节点的个数

 另外一个命令：sync path

sync方法会强制客户端所连接的服务器状态与leader的状态同步，这样在读取 path 的值就是最新的值了。

二、hbase与zookeeper的关系

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

1).HA管理：

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

2).RegionServer管理：

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

   备注：

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

3).元数据Region：

    每次客户端向HBase发起请求时，都会去查询元数据Region,默认目录是：

/hbase-unsecure/meta-region-server,如果发生region的迁移，zookeeper都会进行试试更新，以便其他客户端请求时，总能查到最新的RootRegion信息。

4).Region管理：

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

5).预写日志恢复

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

三、HBase的znode

    HBase在zookeeper的znode的根节点是通过hbase-site.xml中的“zookeeper.znode.parent”属性进行配置的（/hbase-unsecure），每次HBase集群重启znode都会重建，所以如果集群重启的话，重启之前直接删除/hbase-unsecure也是没有问题的。下面就具体讲解下HBase在ZooKeeper中znode目录结构：

replication：

meta-region-server：

    HBase元数据表Region位置信息，在哪个Regionsever上;

rs：

        RS的临时节点,应该是只有在线RegionServer节点，宕机、掉线没有。

splitWAL：

    WAL预写分割工作分配目录

backup-masters:

    备用HMaster节点

table-lock:    

       表锁节点会有所有表

flush-table-proc:

    flush进程

region-in-transition:

    处于RIT状态的region

online-snapshot:

   快照

master:

    激活HMaster节点

balancer:

    正在进行balance的节点

recovering-regions:

    正在恢复的region

namespace：

     HBase集群所有命名空间

hbaseid：

    HBase集群的唯一ID

table：

    集群中各个表信息

“HBase依赖Zookeeper原因分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！


当前文章：HBase依赖Zookeeper原因分析
本文路径：http://pwwzsj.com/article/phooio.html

其他资讯