ZooKeeper 基本概念:特点数据模型节点特性WatcherACL
Posted 凌桓丶
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ZooKeeper 基本概念:特点数据模型节点特性WatcherACL相关的知识,希望对你有一定的参考价值。
文章目录
什么是ZooKeeper?
ZooKeeper是一个开源的分布式协调服务,由知名互联网公司雅虎创建,是Google Chubby的开源实现。它的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。
原语: 操作系统或计算机网络用语范畴。是由若干条指令组成的,用于完成一定功能的一个过程。具有不可分割性·即原语的执行必须是连续的,在执行过程中不允许被中断。
特点
ZooKeeper可以保证如下分布式一致性特性:
- 顺序一致性:从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到 ZooKeeper 中去。
- 原子性:所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。
- 单一视图:无论客户端连到哪一个 ZooKeeper 服务器上,其看到的服务端数据模型都是一致的。
- 可靠性:一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖。
- 实时性:ZooKeeper保证在一定时间段内,客户端最终一定能够从服务端上读取到最新的数据状态。
设计目标
ZooKeeper致力于实现一个高性能、高可用,具有严格顺序访问控制能力(主要是写操作的严格顺序性)的分布式协调服务。高性能使得ZooKeeper能够应用于那些对系统吞吐有明确要求的大型分布式系统,高可用使得分布式的单点问题得到了很好的解决,而严格的顺序访问控制使得客户端能够基于ZooKeeper实现一些复杂的同步原语。
针对以上需求,ZooKeeper的四个设计目标如下:
- 简单的数据模型:ZooKeeper使用一个共享的、树形结构的命名空间来协调分布式程序。其数据模型类似一个文件系统,不过与传统的文件系统不同,ZooKeeper将全量数据存储在内存中,以此来实现提高服务器吞吐、减少延迟的目的。
- 可以构建集群:一个ZooKeeper集群通常由一组机器组成,组成ZooKeeper集群的每台机器都会在内存中维护当前服务器状态,并且每台机器之间都互相保持通信。只要集群中存在半数以上的机器能够正常工作,整个集群就可以正常对外提供服务。
- 顺序访问:对于来自客户端的每个更新请求,ZooKeeper都会分配一个全局唯一的递增编号,这个编号反映了所有事务操作的先后顺序,可以根据这个特性来实现更高层次的同步原语。
- 高性能:由于ZooKeeper将全量数据存储在内存中,并直接服务于客户端的所有非事务请求,因此它尤其适用于以读操作为主的应用场景。
应用场景
ZooKeeper是一个典型的分布式数据一致性的解决方案,通常用于以下这些场景:
- 数据发布/订阅
- 负载均衡
- 命名服务
- 分布式协调/通知
- 集群管理
- Master选举
- 分布式锁
- 分布式队列
系统模型
数据模型
ZooKeeper数据存储的结构与标准的Unix文件系统非常类似,但是并没有引入传统文件系统中目录和文件等概念,而是使用了其特有的数据节点的概念,我们称之为ZNode
。Znode
是zookeeper中的最小数据单元,每个Znode
上都可以保存数据,同时还可以挂载子节点,形成一个树形化命名空间。
如上下图,Znode
的节点路径标识方式和Unix文件系统路径非常相似,都是由一系列使用斜杠(/)进行分割的路径表示,最上层的根结点以/
代表,并且每个Znode
都有一个唯一的路径标识。
⚠️注意:ZooKeeper 主要是用来协调服务的,而不是用来存储业务数据的,所以不要放比较大的数据在 znode 上,ZooKeeper 给出的上限是每个结点的数据大小最大是 1M。
节点特性
节点类型
在ZooKeeper中,Znode
节点类型分为持久节点(PERSISTENT)、临时节点(EPHEMERAL)、**顺序节点(SEQUENTIAL)**三大类,通过组合使用,可以生成以下四种组合型节点类型:
- 持久节点:该数据节点被创建后,就会一直存在于ZooKeeper的服务器上,直到有删除操作来主动清除这个节点。
- 持久顺序节点:基本特性与持久节点一致,额外的特性是顺序性,即一个父节点可以为其子节点维护一个创建的先后顺序 ,这个顺序体现在节点名称上,是节点名称后自动添加一个由 10 位数字组成的数字串,从 0 开始计数,上限是整型最大值。
- 临时节点:临时节点的生命周期与客户端的会话绑定在一起,如果客户端会话失效,则这个节点就会自动被清理掉。同时,临时节点不能创建子节点,它只能作为叶子节点使用。
- 临时顺序节点:基本特性与临时节点一致,额外的特性是顺序性。
节点状态
每个数据节点除了存储数据内容之外,还存储了数据节点本身的一些状态信息(如子节点数量、事务id、版本信息等),这些状态信息由Stat
这个类来维护。
czxid
:Created ZXID
,该数据节点被创建时的事务ID。mzxid
:Modified ZXID
,节点最后一次被更新时的事务ID。ctime
:Created Time
,该节点被创建的时间。mtime
:Modified Time
,该节点最后一次被修改的时间。version
:节点的版本号。cversion
:子节点的版本号。aversion
:节点的ACL
版本号。ephemeralOwner
:创建该节点的会话的sessionID
,如果该节点为持久节点,该值为0。dataLength
:节点数据内容的长度。numChildre
:该节点的子节点个数,如果为临时节点为0。pzxid
:该节点子节点列表最后一次被修改时的事务ID,注意是子节点的列表 ,不是内容。
版本
ZooKeeper中为节点引入了版本的概念,每个数据节点都具有三种类型的版本信息,对数据节点的任何更新操作都会引起版本号的变化。
- dataVersion:当前
Znode
节点数据内容版本号 - cversion:当前
Znode
节点的子节点版本号。 - aclVersion:当前
Znode
的ACL变更版本号。
为了解决那些数据更新竞争激烈的场景,ZooKeeper借助版本号机制来实现乐观并发控制。
Watcher
Watcher(事件监听器),是ZooKeeper中的一个很重要的特性。ZooKeeper允许客户端在指定节点上注册一些 Watcher,并且在一些特定事件触发的时候,ZooKeeper服务端会将事件通知到感兴趣的客户端上去,该机制是 ZooKeeper 实现分布式协调服务的重要特性。
从上图中我们可以看到,ZooKeeper的Watcher机制主要包括客户端线程、客户端WatchManager、ZooKeeper服务器三个部分。工作流程如下:
- 客户端向ZooKeeper服务器注册Watcher对象
- 客户端将Watcher对象存储在客户端的WatchManager中。
- 当ZooKeeper服务器触发Watcher事件后,会向客户端发送通知。
- 客户端从WatchManager中取出对应的Watcher对象来执行回调逻辑。
ACL
ZooKeeper提供了一套完善的ACL(Access Control Lists)权限控制机制来保障数据的安全,类似于Unix/Linux中的UGO权限控制机制。
ACL机制由以下三部分组成,我们通常使用scheme:id:permission
来标识一个有效的ACL信息。
- 权限模式(Scheme)
- 授权对象(ID)
- 权限(Permission)
权限模式:Scheme
权限模式是用来确定权限验证过程中使用的校验策略。在ZooKeeper中最常用的就是以下四种权限模式
- IP:IP模式通过IP地址粒度来进行权限控制。
- Digest:Digest是最常用的权限控制模式,其以类似于
username:password
形式的权限标识来进行权限配置,便于区分不同应用来进行权限控制。当我们配置了权限标识后,为了保证安全,ZooKeeper会分别使用SHA-1算法和BASE64编码进行处理,将其混淆为无法辨识的字符串。 - World:World是最开放的权限控制模式,是一种特殊的Digest模式。在该模式下数据节点的访问权限对所有用户开放,即所有用户都可以在不进行任何数据校验的情况下操作ZooKeeper上的数据。权限标识为
world:anyone
- Super:Super模式即超级用户模式,是一种特殊的Digest模式。在该模式下超级用户可以对任意ZooKeeper上的数据节点进行任何操作。
权限对象:ID
授权对象指的是权限赋予的用户或一个指定实体,例如IP地址或是机器等。在不同的权限关系下,授权对象是不同的,对应关系如下图:
- IP:通常是一个IP地址或者一个IP网段,如
192.168.0.110
或192.168.0.1/24
- Digest:Digest是最常用的权限控制模式,其以类似于
username:password
形式的权限标识来进行权限配置,便于区分不同应用来进行权限控制。当我们配置了权限标识后,为了保证安全,ZooKeeper会分别使用SHA-1算法和BASE64编码进行处理,将其混淆为无法辨识的字符串。 - World:只有一个ID:
anyone
- Super:与Digest模式一致。
权限:Permission
权限就是指那些通过权限检查后可以被允许执行的操作。在ZooKeeper中,所有对数据的操作权限分为以下五大类:
- CREATE:数据节点的创建权限,允许授权对象在该数据节点下创建子节点。
- DELETE:数据节点的删除权限,允许授权对象删除该数据节点的子节点。
- READ:数据节点的读取权限,允许授权对象访问该数据节点并读取其数据内容或子节点列表等。
- WRITE:数据节点的更新权限,允许授权对象对该数据节点进行更新操作。
- ADMIN:数据节点的管理权限,允许授权对象在该数据节点进行ACL相关的设置操作。
Session
Session(会话) 可以看作是ZooKeeper服务器与客户端的之间的一个TCP长连接,通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向ZooKeeper服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的Watcher事件通知。
Session有一个属性叫做:sessionTimeout
,sessionTimeout
代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时,只要在sessionTimeout
规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。
另外在每次客户端向服务端发起会话创建请求时,服务端都会为其分配一个SessionID,SessionID用来唯一标识一个会话,因此ZooKeeper必须保证SessionID的全局唯一性。
以上是关于ZooKeeper 基本概念:特点数据模型节点特性WatcherACL的主要内容,如果未能解决你的问题,请参考以下文章