zookeeper二

Zookeeper的功能模块介绍

1:ZK数据模型(节点模型)
a: Zookeeper的数据模型跟标准的unix文件系统非常类似 , 引入了”数据节点”概念 , 我们称之为ZNode ;
b:ZNode是Zookeeper中数据的最小单元 , 每个ZNode上都可以保存数据 , 同时还可以挂载子节点 , 因此可以构成层次化的ZNode 树 ;
c:每个Znode都可以保存数据(byte[]类型) , 可以对Znode中的数据进行读写操作 , 还存储了该节点本身的状态信息 , 可以创建子节点 (数据信息+状态信息+子节点);
d:节点路径 , 用斜线进行分割 /Zoo/AA ;

2:ZK节点特性
a:节点类型 (znode节点是有生命周期的, 其生命周期的长短取决于数据节点类型)
znode的节点类型分为:
持久性节点(persistent) : 如果创建一直保存在zk服务器上 , 直到有删除操作来删除该节点 ;
持久顺序节点(persistent_sequential): 在ZK中每个父节点都会为他的第一级子节点维护一份顺序 , 用来记录每个子节点的创建顺序 , 该节点创建时 , zk 会自动给节点名加一个数字后缀 , 做为新的完整的节点名 ;
临时节点(ephemeral): 临时节点的生命周期跟客户端会话绑定一起 , 如果客户端会话失效 , 节点自动清除 , 该节点下不能创建子节点 ;
临时顺序节点(ephemeral_sequential): 临时节点的基础上 , 添加了顺序的特性 ;
b:节点状态

3:ZK版本
a:zk的版本保证了分布式数据原子性的操作
znode的节点版本类型分为:
version:当前节点的数据内容的版本号 ;
aversion:当前节点的ACL信息变更版本号 ;
cversion: 当前节点的子节点的版本号 ;
b:在并发的环境中 , 我们需要通过一些机制来保证数据在某个操作过程中不会被外界修改 , 称这种机制为锁 , 在数据库技术中 , 有悲观锁 和 乐观锁 , 就是这种机制的典型实现 ;
悲观锁(pessimistic concurrency control pcc 悲观并发控制) :具有强烈的独占性 和 排他性 , 对于一份独立的数据 , 系统只分配一把唯一的钥匙 , 谁获得这把钥匙 , 谁就有权利更新这份数据 ;
乐观锁(optimistic concurrency control 乐观并发控制): 乐观锁认为 , 在多个事务在处理的过程中不彼此影响,在事务处理的大部分时间里 , 不需要进行加锁处理 , 但是在更新请求提交之前 , 每个事务都会检查当前事务读取的数据 后 , 是否有其它的事务对它进行修改 , 如果其它事务有更新的话 , 那将提交的事务进行回滚 , 适合数据竞争不大 , 事务冲突较少的场景 ; (数据的读取 + 写入校验 + 数据写入)
jdk CAS (compare and swap )是乐观锁典型的实现
c:zookeeper 中的version 属性是用来实现乐观锁机制中的”写入校验” ;

4:Watcher ---数据变更的通知
a:zk提供了分布式数据的发布/订阅功能 ;
b:在zookeeper中 , 引入了watcher机制来实现分布式的通知功能 , zookeeper允许客户端向服务端注册一个watcher 监听 , 当服务端的一些指定事件触发了这个watcher , 那么就会向指定的客户端发送一个事件通知 , 来实现分布式的通知功能 ;

5.:Zookeeper 的Watcher工作机制
Zookeeper 的watcher 工作机制分为四个过程: 客户端注册watcher , 服务端处理watcher , watcher的触发 ,客户端回调watcher ;

a:Watcher 接口类

a:Watcher 接口:
接口类Watcher 用于表示一个标准的事件处理器 , 定了事件通知和处理相关的逻辑 , 包括KeeperState 和EventType 两个枚举类 , 代表通知状态 和 事件类型 , 同时定义了事件的回调方法:
process(WatcherEvent)
b:Watcher 事件:
watcher 同一个事件类型 , 在不同通知状态下代表的含义是不同:

 

1.调用zkclient api , 将watcher 和 znode 节点路径封装到 watchRegistration 中 , 并将请求标记为使用watcher的请求
2. 将watchRegistration 封装到 packet 中 , 在将 packet 放到 outgingQueue 队列中等待 SendThread 线程发送到zkServer端 ;
3.SendThread 线程中 readResponse 方法负责接收来自zkServer端响应 ;
4.当zkServer端 处理完成 ,得到正确的响应后 , finishPacket 方法 将 负责 从 packet 中取出 watcher , 将注册到zkWatchManager 中
5.Watcher 虽然被放到packet 中 , 但是packet 序列号时并没有将watcher发送zkserver端 , 只是将RequestHeader和 request 序列化发送到 服务端

Zookeeper 类结构

Zookeeper 中ClientCnxn 类结构

Watcher 事件的说明&Wather注册
a:NodeDataChanged
--- 数据节点的数据内容发生变化 或者 数据的版本发生变化都会触发
--- 无论数据内容是否变更 , 如果客户端调用了数据更新的接口 , 且更新成功 , 就会更新dataVersion值就会触发
b:NodeChildrenChanged
--- 新增节点 或者 删除节点 都会触发
c: AuthFailed
--- 不是因为客户端会话没有权限 , 而是因为授权失败才去触发

Zookeeper 服务端处理watcher

Zookeeper 服务端watcher的触发的过程

Zookeeper 客户端watcher的回调

Zookeeper 的ACL

1.ZooKeeper 提供了一套完善的ACL(Access Control List)权限控制机制 , 来保证zkServer 上的znode的数据操作的安全性
2.向大家比较熟悉的linux 文件权限系统 UGO (User , Group , Others) 权限控制机制 , 是粗粒的权限控制
3.ACL 属于细粒度的权限控制
4. ACL 通过提供 , 权限模式 (Scheme) , 授权对象 (ID), 权限 (Permmision), 通常是 Scheme:id:permission来标识一个有效的ACL 信息

1.通过auth 给某个znode添加权限 , user:password 是明文 ;
2. 通过auth 给某个znode添加权限时 , 先将 ID 加入到zk中 , addauth digest node2u:11111 ;
3.auth 本质就是 digest , digest 是密文 ;
4.Zookeeper的功能模块介绍

Zookeeper 的客户端

1.Zookeeper客户端开源的产品有 ZkClient 和 Curator ;
1-1: ZkClient
-- zkclient 对zookeeper原生的API进行封装
-- 解决session 会话超时重连 ;
-- Watcher 反注册 , 简化开发api
-- https://github.com/sgroschupf/zkclient
1-2:Curator
-- 解决session会话超时重连 ;
-- watcher 反复注册 ;
-- 简化开发api ;
-- 遵循Fluent风格api规范
-- NodeExistsException 异常处理
-- 共享锁服务 , master选举 , 分布式计数器等
-- http://curator.apache.org/