ZooKeeper的Znode剖析

版权声明:本文为博主原创文章,转载请注明出处: http://blog.csdn.net/lihao21

目录(?)[-]

  1. 类型
    1. 持久节点
    2. 临时节点
    3. 顺序节点
  2. 节点的数据
  3. 节点的属性
    1. 版本号
    2. 事务ID
    3. 时间戳
  4. 参考资料

在ZooKeeper中,节点也称为znode。由于对于程序员来说,对zk的操作主要是对znode的操作,因此,有必要对znode进行深入的了解。 
ZooKeeper采用了类似文件系统的的数据模型,其节点构成了一个具有层级关系的树状结构。例如,图1展示了zk节点的层级树状结构。

 
图1:ZooKeeper的层级树状结构

图1中,根节点 / 包含了两个字节点 /module1,/module2,而节点 /module1 又包含了三个字节点 /module1/app1,/module1/app2,/module1/app3。在zk中,节点以绝对路径表示,不存在相对路径,且路径最后不能以 / 结尾(根节点除外)。

类型

根据节点的存活时间,可以对节点划分为持久节点和临时节点。节点的类型在创建时就被确定下来,并且不能改变。 
持久节点的存活时间不依赖于客户端会话,只有客户端在显式执行删除节点操作时,节点才消失。 
临时节点的存活时间依赖于客户端会话,当会话结束,临时节点将会被自动删除(当然也可以手动删除临时节点)。利用临时节点的这一特性,我们可以使用临时节点来进行集群管理,包括发现服务的上下线等。 
ZooKeeper规定,临时节点不能拥有子节点。

持久节点

使用命令create可以创建一个持久节点。

create /module1 module1

这样,便创建了一个持久节点/module1,且其数据为”module1”。

临时节点

使用create命令,并加上-e参数,可以创建一个临时节点。

create -e /module1/app1 app1

这样,便创建了一个临时节点 /module1/app1,数据为”app1”。关闭会话,然后输入命令:

get /module1/app1

可以看到有以下提示,说明临时节点已经被删除。

Node does not exist: /module1/app1

顺序节点

ZooKeeper中还提供了一种顺序节点的节点类型。每次创建顺序节点时,zk都会在路径后面自动添加上10位的数字(计数器),例如 < path >0000000001,< path >0000000002,……这个计数器可以保证在同一个父节点下是唯一的。在zk内部使用了4个字节的有符号整形来表示这个计数器,也就是说当计数器的大小超过2147483647时,将会发生溢出。 
顺序节点为节点的一种特性,也就是,持久节点和临时节点都可以设置为顺序节点。这样一来,znode一共有4种类型:持久的、临时的,持久顺序的,临时顺序的。

使用命令create加上-s参数,可以创建顺序节点,例如,

create -s /module1/app app

输出:

Created /module1/app0000000001

便创建了一个持久顺序节点 /module1/app0000000001。如果再执行此命令,则会生成节点 /module1/app0000000002。 
如果在create -s再添加-e参数,则可以创建一个临时顺序节点。

节点的数据

在创建节点时,可以指定节点中存储的数据。ZooKeeper保证读和写都是原子操作,且每次读写操作都是对数据的完整读取或完整写入,并不提供对数据进行部分读取或者写入的操作。 
以下命令创建一个节点/module1/app2,且其存储的数据为app2。

create /module1/app2 app2

ZooKeeper虽然提供了在节点存储数据的功能,但它并不将自己定位为一个通用的数据库,也就是说,你不应该在节点存储过多的数据。Zk规定节点的数据大小不能超过1M,但实际上我们在znode的数据量应该尽可能小,因为数据过大会导致zk的性能明显下降。如果确实需要存储大量的数据,一般解决方法是在另外的分布式数据库(例如Redis)中保存这部分数据,然后在znode中我们只保留这个数据库中保存位置的索引即可。

节点的属性

每个znode都包含了一系列的属性,通过命令get,我们可以获得节点的属性。

get /module1/app2 
app2 
cZxid = 0x20000000e 
ctime = Thu Jun 30 20:41:55 HKT 2016 
mZxid = 0x20000000e 
mtime = Thu Jun 30 20:41:55 HKT 2016 
pZxid = 0x20000000e 
cversion = 0 
dataVersion = 0 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 4 
numChildren = 0

版本号

对于每个znode来说,均存在三个版本号:

  • dataVersion 
    数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据)。
  • cversion 
    子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。
  • aclVersion 
    ACL的版本号,关于znode的ACL(Access Control List,访问控制),可以参考 参考资料1 有关ACL的描述。

以数据版本号来说明zk中版本号的作用。每一个znode都有一个数据版本号,它随着每次数据变化而自增。ZooKeeper提供的一些API例如setData和delete根据版本号有条件地执行。多个客户端对同一个znode进行操作时,版本号的使用就会显得尤为重要。例如,假设客户端C1对znode /config写入一些配置信息,如果另一个客户端C2同时更新了这个znode,此时C1的版本号已经过期,C1调用setData一定不会成功。这正是版本机制有效避免了数据更新时出现的先后顺序问题。在这个例子中,C1在写入数据时使用的版本号无法匹配,使得操作失败。图2描述了这个情况。

图2:使用版本号来阻止并行操作的不一致性

事务ID

对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生。 
需要指出的是,zxid对于整个zk都是唯一的,即使操作的是不同的znode。

  • cZxid 
    Znode创建的事务id。
  • mZxid 
    Znode被修改的事务id,即每次对znode的修改都会更新mZxid。

 
图3:Zxid在客户端重连中的作用

在集群模式下,客户端有多个服务器可以连接,当尝试连接到一个不同的服务器时,这个服务器的状态要与最后连接的服务器的状态要保持一致。Zk正是使用zxid来标识这个状态,图3描述了客户端在重连情况下zxid的作用。当客户端因超时与S1断开连接后,客户端开始尝试连接S2,但S2延迟于客户端所识别的状态。然而,S3的状态与客户端所识别的状态一致,所以客户端可以安全连接上S3。

时间戳

包括znode的创建时间和修改时间,创建时间是znode创建时的时间,创建后就不会改变;修改时间在每次更新znode时都会发生变化。

以下命令创建了一个 /module2 节点。

create /module2 module2 
Created /module2

通过 get 命令,可以看到 /module2的 ctime和mtime均为Sat Jul 02 11:18:32 CST 2016。

get /module2 
module2 
cZxid = 0x2 
ctime = Sat Jul 02 11:18:32 CST 2016 
mZxid = 0x2 
mtime = Sat Jul 02 11:18:32 CST 2016 
pZxid = 0x2 
cversion = 0 
dataVersion = 0 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 7 
numChildren = 0

修改 /module2,可以看到 ctime 没有发生变化,mtime已更新为最新的时间。

set /module2 module2_1 
cZxid = 0x2 
ctime = Sat Jul 02 11:18:32 CST 2016 
mZxid = 0x3 
mtime = Sat Jul 02 11:18:50 CST 2016 
pZxid = 0x2 
cversion = 0 
dataVersion = 1 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 9 
numChildren = 0

参考资料

  1. http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkDataModel
  2. http://java.globinch.com/enterprise-services/zookeeper/apache-zookeeper-explained-tutorial-cases-zookeeper-java-api-examples/#
  3. 《ZooKeeper分布式过程协同技术详解》,Flavio Junqueira等著,谢超等译
时间: 2024-08-29 19:37:21

ZooKeeper的Znode剖析的相关文章

zookeeper监控znode

package zookeeper; import java.util.List; import org.apache.zookeeper.KeeperException; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.Watcher; import org.apache.zookeeper.Watcher.Event.EventType; import org.apache.zookeeper.Zoo

ZooKeeper的znode说明和znode状态

1.znode znode的官方说明:http://zookeeper.apache.org/doc/r3.4.12/zookeeperProgrammers.html#sc_zkDataModel_znodes ZooKeeper以一种类似于文件系统的树形数据结构实现名称空间.名称空间中的每个节点都是一个znode.znode和文件系统的路径不一样,在文件系统中,路径只是一个名称,不包含数据.而znode不仅是一个路径,还携带数据. 此外,znode还维护了包括版本号和时间戳的状态信息.通过版

浅谈分布式服务协调技术 Zookeeper

Google的三篇论文影响了很多很多人,也影响了很多很多系统.这三篇论文一直是分布式领域传阅的经典.根据MapReduce,于是我们有了Hadoop:根据GFS,于是我们有了HDFS:根据BigTable,于是我们有了HBase.而在这三篇论文里都提及Google的一个Lock Service -- Chubby,哦,于是我们有了Zookeeper. 随着大数据的火热,Hxx们已经变得耳熟能详,现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼.但实际上对我们这些非大数据开发

ZooKeeper架构设计及其应用要点

ZooKeeper是一个开源的分布式服务框架,它是Apache Hadoop项目的一个子项目,主要用来解决分布式应用场景中存在的一些问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置管理等,它支持Standalone模式和分布式模式,在分布式模式下,能够为分布式应用提供高性能和可靠地协调服务,而且使用ZooKeeper可以大大简化分布式协调服务的实现,为开发分布式应用极大地降低了成本. 总体架构 ZooKeeper分布式协调服务框架的总体架构,如图所示: ZooKeeper集群由一组

zookeeper基本讲解(Java版,真心不错)

1. 概述 Zookeeper是Hadoop的一个子项目,它是分布式系统中的协调系统,可提供的服务主要有:配置服务.名字服务.分布式同步.组服务等. 它有如下的一些特点: 简单 Zookeeper的核心是一个精简的文件系统,它支持一些简单的操作和一些抽象操作,例如,排序和通知. 丰富 Zookeeper的原语操作是很丰富的,可实现一些协调数据结构和协议.例如,分布式队列.分布式锁和一组同级别节点中的“领导者选举”. 高可靠 Zookeeper支持集群模式,可以很容易的解决单点故障问题. 松耦合交

Zookeeper简单介绍

转自:ZooKeeper学习第一期---Zookeeper简单介绍 一.分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术--分布式协调技术.那么什么是分布式协调技术?那么我来告诉大家,其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制,让他们有序的去访问某种临界资源,防止造成"脏数据"的后果.这时,有人可能会说这个简单,写一个调 度算法就轻松解决了.说这句话的人,可能对分布式系统不是很了解,所以才会出现这种误解.如果这些进程全部是跑在一台机上的

ZooKeeper搭建系列集 (这套很全,也很详细)

原文链接:http://blog.csdn.net/shatelang/article/details/7596007 本篇文章结构: 总共包括10个系列 ZooKeeper系列之一:ZooKeeper简介 ZooKeeper系列之二:ZooKeeper数据模型.命名空间以及节点的概念 ZooKeeper系列之三:ZooKeeper的安装 ZooKeeper系列之四:ZooKeeper的配置 ZooKeeper系列之五:ZooKeeper的运行 ****************** ------

zookeeper理论

1.1.1    Zookeeper的保证 l         顺序性,client的updates请求都会根据它发出的顺序被顺序的处理: l         原子性,  一个update操作要么成功要么失败,没有其他可能的结果: l         一致的镜像,client不论连接到哪个server,展示给它都是同一个视图: l         可靠性,一旦一个update被应用就被持久化了,除非另一个update请求更新了当前值 l         实时性,对于每个client它的系统视图都

hadoop系列:zookeeper(3)——zookeeper核心原理(事件)

1.概述 上一篇文章,我们对zookeeper中的数据组织结构.Leader选举原理进行了讲述(http://blog.csdn.net/yinwenjie/article/details/47613309).这篇文章我们紧接上文讲解zookeeper中的事件机制.并通过示例代码告诉读者怎么使用zookeeper中的事件通知器:watcher. 2.zookeeper中的监听机制 按照上文中的讲解,我们知道zookeeper主要是为了统一分布式系统中各个节点的工作状态,在资源冲突的情况下协调提供