Zookeeper

第一章 Zookeeper基础

---

---

一、分布式特性

• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格按照其顺序被应用到Zookeeper中去
• 原子性：所有的事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。
• 单一视图：无论客户端连接的是哪个Zookeeper服务器，其看到的服务器数据模型都是一致的
• 可靠性：一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了变更。
• 实时性：Zookeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端读取到最新的数据状态。

二、集群角色

• Leader：事务请求的唯一调度和处理者，保证集群事务处理的顺序性；集群内各服务器的调度者
• Follower：处理客户端非事务请求，转发事务请求给Leader服务器；参与事务请求Proposal投票；参与Leader选举投票
• Observer：处理客户端非事务请求，转发事务请求给Leader服务器；不参与事务请求Proposal投票和Leader选举投票。

三、Session

只要在sessionTimeout 时间内，连上任意一个实例，session都有效。下图是session状态转换图：

四、数据节点

zookeeper将所有的数据存储在内存中，数据模型是一棵树，有/进行分割的路径，就是一个数据节点Znode。每个ZNode上都会保存自己的数据内容，和其他信息。
数据节点分为PERSISTENT、EPHEMERAL、SEQUENTIAL、CONTAINER、TTL，组合起来一共是7类：

• PERSISTENT
  持久化，不会随客户端的断开而自动删除,默认类型
• PERSISTENT_SEQUENTIAL
  带序号的持久化，znode的名字将被附加一个单调递增的数字
• EPHEMERAL
  临时节点，当客户端断开时自动删除
• EPHEMERAL_SEQUENTIAL
  带序号的临时节点，znode的名字将被附加一个单调递增的数字
• CONTAINER
  container节点是一个特殊用途的节点，对于诸如leader、lock等非常有用。当容器的最后一个子对象被删除时，该容器将成为将来某个时候由服务器删除的候选对象。
• PERSISTENT_TTL
  zookeeper的扩展类型，如果znode在给定的TTL内没有被修改，它将在没有子节点时被删除。要想使用该类型，必须在zookeeper的bin/zkService.sh中的启动zookeeper的java环境中设置环境变量zookeeper.extendedTypesEnabled=true，否则KeeperErrorCode = Unimplemented for /**。
• PERSISTENT_SEQUENTIAL_TTL
  带序号的，其他同持久TTL节点

[zk: localhost:2181(CONNECTED) 14] get -s /com/johar/middleware/schedule/exec
"1"
cZxid = 0x90000000b  // 数据节点创建时的事务ID
ctime = Sun Dec 26 17:37:55 CST 2021 // 数据节点创建时的时间
mZxid = 0x9000000ef // 数据节点最后一次更新时的事务ID
mtime = Sun Dec 26 22:50:30 CST 2021 // 数据节点最后一次更新时的时间
pZxid = 0x90000000b // 数据节点的子节点列表最后一次被修改（是子节点列表变更，而不是子节点内容变更）时的事务ID
cversion = 0 // 子节点的版本号子节点的版本号
dataVersion = 1 // 数据节点的版本号
aclVersion = 0 // 数据节点的ACL版本号 
ephemeralOwner = 0x0 // 如果节点是临时节点，则表示创建该节点的会话的SessionID；如果节点是持久节点，则该属性值为0
dataLength = 3 // 数据内容的长度
numChildren = 0 // 数据节点当前的子节点个数
1
2
3
4
5
6
7
8
9
10
11
12
13

五、Watcher

Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端上。

• 一次性
  一个Watcher一旦被处罚，Zookeeper都会将其从相应的存储中移除。也就是注册一次Watcher，只能接收到一次变更事件。
• 客户端串行执行
  客户端Watcher 回调的过程是一个串行同步的过程，保证了顺序，但是不能因为一个Watcher的处理逻辑影响了整个客户端的Watcher回调。
• 轻量
  WatchedEvent 是Zookeeper整个Watcher通知机制的最小通知单元，这个数据结构只包含三部分内容：通知状态，事件类型和节点路径。换句话说，Watcher通知只告诉客户端发了事件，但是不会说明事件的具体内容。
  

六、ACL

Zookeeper使用ACL机制实现对数据节点内容权限控制，使用“scheme : id : permission”来标识一个有效的ACL信息，其中scheme：权限模式，id：授权对象，permission：授权对象。

1. 权限模式：Scheme

在Zookeeper中，有以下四种权限模式：

• IP
  IP模式通过IP地址粒度来进行权限控制。
• Digest
  类似“username:password”形式的权限表示来进行权限配置，便于区分不同应用来进行权限控制。
• World
  最开放的权限控制模式，数据节点的访问权限对所有的用户开放。权限标识为：“world:anyone”
• Super
  超级用户的模式，超级用户可以对任意Zookeeper上的数据节点进行任何操作。

2. 授权对象：ID

授权对象是指权限赋予的用户或者一个指定实体。

3. 权限：Permission

权限就是指那些通过权限检查后可以被允许执行的操作。

• CREATE（C）：数据节点的创建权限，允许授权对象在该数据节点下创建子节点
• DELETE（D）：子节点的删除权限，允许授权对象删除该数据节点的子节点。
• READ（R）：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等。
• WRITE（W）：数据节点更新权限，允许授权对象对该数据节点进行更新操作。
• ADMIN（A）：数据节点的管理权限，允许授权对象对该数据节点进行ACL相关的设置操作。