Zookeeper简介
这篇文章是旨在为那些想要利用Zookeeper协调服务能力进行分布式应用创建的开发者的入门指导,包括一些理论性和实践性的内容。
文章的前四部分系统的介绍了zookeeper的相关概念,对于理解zookeeper的工作机制及使用都有很大帮助。
-
zookeeper的数据结构
-
zookeeper会话
-
zookeeper监听
-
一致性保障
-
文章的后四部分包含一些训练性的编程内容,包括:
-
zookeeper操作指引
-
绑定关系
-
项目结构
-
常见问题及解决
一、zookeeper数据结构
zookeeper本身是一种层次性的命名空间结构,非常类似于分布式文件系统,不同之处在于zookeeper的每个节点都可以存储节点数据及拥有子节点,既是文件又是文件夹。每个节点的路径都是用斜线分割,唯一,绝对的。没有相对路径:
二、ZNode
zookeeper中的节点以ZNode的形式存在,ZNode结构存储数据及确认历史变化版本号并包含时间戳。zookeeper使用版本号及时间戳来处理缓存时效及协调更新。版本号会随着每次节点数据的改变而递增,客户端查询节点数据,同时会返回数据的版本号信息,当需要执行删除或更新操作时,客户端必须提供相应的需要删除的数据版本号,如果不一致,则操作不执行。
附注:在分布式应用机制中,一个node可以代表一个host地址,一台服务器,集合中的一员,一个客户端进程等,zookeeper中znodes代表数据节点,servers对应组成zookeeper服务的机器,client代表使用zookeeper服务的任何客户端进程,quorum peers代表组成集合的服务器。
znodes是编程主要涉及的对象,主要特性如下:
-
监听:客户端可以设置节点监听,当节点发生变化(数据变化或者被删除等)将会触发监听并通知监听客户端,触发后删除监听。
-
数据访问:节点数据访问具有原子性,读取或者更新全部输的数据信息,每个节点都有一个访问控制列表,进行权限控制。zookeeper设计的初衷并不是用来作为常规的数据库的,相反,他维护一致性数据,包括配置信息,状态信息,会合信息等,它们共同的特点就是数据量特别小,Kbits大小,zookeeper客户端和服务端有一套健全的机制检查节点数据的大小,确保不大于1M,通常来说会大大小于1M。大体积数据操作会耗费更多的时间在网络传输上,从而会影响其它相关操作,通常不建议。如果要存储大体积的数据,通常的做法是将数据存放在文件系统,然后将指向地址存储在zookeeper节点中。
-
临时节点:临时节点是一种节点,它会随着创建它的会话的生命周期而存在,会话结束,则节点删除,因为这一特性,临时节点没有子节点。
-
顺序节点(唯一命名):创建节点的时候,可以设置zookeeper单纯的增加路径末端的节点序号。节点序号相对于父节点是唯一的,按照10位前端补零的格式来格式化并排序,4bytes无符号整数,当节点超过2147483647是会发生溢出异常。
-
容器节点:3.6.0之后增加
-
容器节点是专门为了应用于leader选举,分布式锁等而添加的特殊节点形式。当容器节点的最后一个子节点被删除,容器节点就会被列入zookeeper服务将要删除的节点行列。
-
当在容器节点下创建子节点时,需要捕获NoNodeException异常,当容器节点不存在是先执行容器节点的创建。
-
三、zookeeper中的时间:
- Zxid:zookeeeper的状态变化会以唯一zxid(ZooKeeper Transaction Id)的形式印记,用以标识zookeeper的状态变化顺序,小序号先于大序号发生。
-
版本号:节点的变化会以节点的一种版本号变化来标记,节点包含三种版本号:version指代节点数据的变化;cversion指代节点子节点的变化;aversion指代节点的acl变化。
-
Ticks:当使用多服务zookeeper时,服务之间使用ticks来作为基本的时间单位来同步协调,例如状态上载,会话过期,终端连接的过期。
-
Real time:zookeeper内部不适用时钟时间,唯一的用处是作为节点的时间戳数据插入和修改。
-
- zookeeper状态数据结构:
-
czxid:节点创建唯一标识
-
mzxid: 节点更新唯一标识
-
pzxid:子节点更新
-
ctime:节点创建过去的毫秒数
-
mtime:节点更新过去的毫秒数
-
version:节点数据变更的版本号
-
cversion:子节点数据变更的版本号
-
aversion:节点ACL变更的版本号
-
ephemeralowner:临时节点拥有者的会话id
-
dataLength:节点数据长度
-
numChildren:节点的子节点数。
-