【ZooKeeper】分布式协作框架ZooKeeper

版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/gongxifacai_believe/article/details/81138818

1、ZooKeeper概述

Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式通知协调等。Zookeeper对分布式开发带来很多便利,用ZK的独有特性巧妙地解决了很多难题,很多分布式技术用到Zookeeper或多或少特性,越来越多的分布式计算开始强依赖ZK,尤其是新生代分布式技术几乎都会依赖Zookeeper特性,比如Storm、Hbase。

2、ZooKeeper架构

Server端具有fast fail特性,非常健壮,无单点故障。不超过半数Server挂掉不影响提供服务。Master/slave是主流模式。

3、ZooKeeper的命名空间

Zookeeper名字空间由节点znode构成,其组织方式类似HDFS文件系统,为目录树型结构,其中各个节点相当于目录和文件,通过路径作为唯一标识,如上图中的/NameService/Server1。与文件系统不同的是,每个节点具有与之对应的数据内容,同时也可以具有子节点。Zookeeper用于存储协调数据,如状态、配置、位置等信息,每个节点存储的数据量很小,大约KB级别。节点维护一个状态stat结构(包括数据变化的版本号、ACL变化、时间戳),以允许缓存验证与协调更新。每当节点数据内容改变,就增加一个版本号,类似HBase。客户端获取数据的同时也会获取数据版本号。节点的数据内容以原子方式读写。节点具有一个访问控制列表(Access Control List - ACL)来约束访问操作,即具有权限控制功能。

4、ZooKeeper中的属性

zk中每一个znode的状态结构由以下域组成:

  • czxid:创建这个znode的 zxid
  • mzxid:最后一次修改这个znode的zxid
  • ctime:以毫秒为单位,这个znode创建的时间
  • mtime:以毫秒为单位, 最后一次修改这个znode的时间
  • version:这个znode被修改的次数
  • cversion:这个znode子节点被修改的次数
  • aversion:这个znode ACL被修改的次数
  • ephemeralOwner:如果这是一个临时节点,存储的是session的id,如果不是临时的,值为0
  • dataLength:这个znode的数据长度
  • numChildren:这个znode的子节点的数量
  • ACL:是针对用户访问的控制

5、ZooKeeper的监听事件

Zookeeper对Node的增、删、改、查都可触发监听。 watch事件是一次性触发器,当watch监视的数据发生变化时,通知设置了该watch的client,即watcher,watch事件异步发送至观察者。在获取watch事件和设置新watch事件之间有延迟,所以不能可靠的观察到节点的每一次变化。客户端监视一个节点,总是先获取watch事件,再发现节点的数据变化,watch事件的顺序对应于zookeeper服务所见的数据更新的顺序。

6、分布式锁

zookeeper集群的每个节点的数据都是一致的,那么我们可以通过这些节点来作为锁的标志,这利用了每个节点的强一致性。 设置分布式锁,首先操作要包含lock(锁住),unlock(解锁),isLocked(是否锁住)三个方法,然后我们可以创建一个工厂(LockFactory),用来专门生产锁。 锁的创建过程如下描述: 前提:每个锁都需要一个路径来指定(如:/lock) (1)根据指定的路径,查找zookeeper集群下的这个节点是否存在(说明已经有锁了); (2)如果存在,根据查询者的一些特征数据(如ip地址/hostname),当前的锁是不是查询者的; (3)如果不是查询者的锁,则返回null,说明创建锁失败; (4)如果是查询者的锁, 则把这个锁返回给查询者; (5)如果这个节点不存在,说明当前没有锁,那么创建一个临时节点,并将查询者的特征信息写入这个节点的数据中,然后返回这个锁。 根据以上5步,一个分布式的锁就可以创建了。 创建的锁有三种状态: (1)创建失败(null),说明该锁被其他查询者使用了; (2)创建成功,但当前没有锁住(unlocked),可以使用; (3)创建成功,但当前已经锁住(locked)了,不能继续加锁。 分布式锁主要用于读完整性要求非常高的数据,比如修改人员信息等场合。

7、ZooKeeper在Hadoop平台中的典型应用

Storm集群:Zookeeper作为nimbus(master)和supervisor(slave)的中间枢纽,保存Storm集群和作业的所有信息,并负责nimbus和supervisor的全部通信,并提供了Fast faill机制。 HBase集群:Zookeeper作为“协调器”,为HBase提供了稳定服务和fail over机制。HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中,使得HMaster可以随时感知到各个HRegionServer的健康状态(可用于监控RegionServer)。此外,Zookeeper也避免了HMaster的单点问题。 ZooKeeper主要用在Storm应用开发,Storm集群监控,MapReduce应用开发和HBase应用开发等方面。

8、分布式应用配置管理

发布与订阅即所谓的配置管理 顾名思义就是将数据发布到zk节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,地址列表等就非常适合使用。 Name Service 这个主要是作为分布式命名服务,通过调用zk的create node api,能够很容易创建一个全局唯一的path,这个path就可以作为一个名称。 分布式通知/协调 ZooKeeper中特有watcher注册与异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行watch,监听znode的变化(包括znode本身内容及子节点的),其中一个系统update了znode,那么另一个系统能够收到通知,并作出相应处理。 分布式锁 分布式锁,这个主要得益于ZooKeeper为我们保证了数据的强一致性,zk集群中任意节点(一个zk server)上的相同znode的数据是一定是相同的。 锁服务可以分为两类,一个是保持独占,另一个是控制时序。 集群管理 Hbase Master选举则是zookeeper经典的使用场景。 分布式队列 队列方面,一种是常规的先进先出队列,另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列,用分布式锁服务来进行时序控制。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券