《从Paxos到Zookeeper》——第四、七章：基本概念及原理

目录

第四章 Zookeeper与Paxos

4.1 Zk是什么

4.1.1 Zk特性

4.1.2 Zk基本概念

4.1.2.1 集群角色(Follower, Leader, Observer)

4.1.2.2 数据模型

4.1.2.3 ZNode(数据节点)

4.1.2.4 Session(会话)

4.1.2.5 ACL（Access Control Lists）

4.1.2.6 Watcher(事件监听器)

4.2 ZAB协议

第七章 Zookeeper技术内幕

7.1 系统模型

7.1.1 数据模型

7.1.2 节点特性

7.1.2.1 节点分类

7.1.2.2 节点数据

7.1.3 版本——保证分布式数据原子性操作

7.1.4 Watcher——数据更变的通知

7.1.5 ACL——保障数据的安全

第四章 Zookeeper与Paxos

4.1 Zk是什么

2010年11月正式成为 Apache 顶级项目
Zk是一个分布式数据一致性的解决方案，提供了高效且可靠的分布式协调服务。
- 应用程序可以基于它实现诸如数据发布/订阅，负载均衡，统一命名服务，分布式协调通知，配置管理，分布式锁，分布式锁等分布式的基础服务（第六章会详细提及）
ZooKeeper 并没有直接采用 Paxos 算法，而是采用了名为 ZAB（Zookeeper Atomic Broadcast）的一致性协议

4.1.1 Zk特性

顺序一致性：所有客户端看到的服务端数据模型都是强一致的；从一个客户端发起的事务请求，最终都会严格按照其发起顺序被应用到 ZooKeeper 中（可见下文，原子广播）
原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用（可见下文：事务）
单一视图：无论客户端连接的是哪个 Zookeeper 服务器，其看到的服务端数据模型都是一致的
高性能：ZooKeeper 将数据全量存储在内存中，所以其性能很高。需要注意的是：由于 ZooKeeper 的所有更新和删除都是基于事务的，因此 ZooKeeper 在读多写少的应用场景中有性能表现较好；如果写操作频繁，性能会大大下滑
高可用：ZooKeeper 的高可用是基于副本机制实现的，此外 ZooKeeper 支持故障恢复（可见下文：选举 Leader）

4.1.2 Zk基本概念

4.1.2.1 集群角色(Follower, Leader, Observer)

没有沿用Master / Slave概念，引入Follower, Leader, Observer三种角色

角色	职责
Leader	读写：提供读写服务：只有Leader会处理集群中所有的写请求，保证数据的一致性负责维护着系统的最新状态，发起并维护与各 Follwer 及 Observer 间的心跳，并负责将状态变更同步给Follower和Observer节点所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader
Follower	提供读服务；接受写请求，但不能直接处理，而需要将写请求转发给 Leader 处理响应 Leader 的心跳将写请求转发给 Leader 处理，并且负责在 Leader 处理写请求时对请求进行投票一个 Zookeeper 集群可能同时存在多个 Follower
Observer	提供读服务；接受写请求，但不能直接处理，而需要将写请求转发给 Leader 处理响应 Leader 的心跳不参与投票

4.1.2.2 数据模型

ZooKeeper 的数据模型是一个树形结构的文件系统（ZNode Tree），树中的节点被称为 ZNode。每个节点上都可以保存数据，并挂上子节点
模型的根节点为 /
节点由斜杠（/）进行分割路径，例如/foo/path1

4.1.2.3 ZNode(数据节点)

ZNode 通过路径被引用，ZNode 节点路径必须是绝对路径
每个ZNode上都会保存自己的数据内容，及一系列属性信息，大小被限制在 1MB 以内
ZNode 两种类型
- 临时节点(EPHEMERAL)：生命周期和客户端会话绑定，会话失效后，这个客户端创建的所有临时节点都会被删除
- 持久节点(PERSISTENT)：持久节点一旦被创立，除非客户端主动删除，否则会一直存在 ZooKeeper 上
ZNode 属性
- SEQUENTIAL：ZNode 上还有一个特殊属性 (SEQUENTIAL，也称顺序标志)。如果在创建 ZNode 时，设置了SEQUENTIAL，那么 ZooKeeper 会使用计数器为该ZNode的节点名后面添加一个单调递增的整型数字（该数字由父节点维护），即 zxid。ZooKeeper 正是利用 zxid 实现了严格的顺序访问控制能力
- Stat(版本)：Zk为每个ZNode维护了一个叫Stat的数据结构，里面记录了这个ZNode的三个数据版本，分别是version(当前ZNode的版本)，cversion(当前ZNode子节点的版本)，aversion(当前ZNode的ACL版本)

4.1.2.4 Session(会话)

在Zk中，客户端启动时，首先通过一个 TCP 长连接连接到 ZooKeeper 服务集群，端口默认2181
Session 从第一次连接开始就已经建立，之后客户端通过心跳检测机制来与服务端保持有效的会话状态。通过这个连接，客户端可以发送请求并接收响应，同时也可以接收到 Watch 事件的通知。
一旦客户端与一台服务器建立连接，这台服务器会为这个客户端创建一个新的会话。每个会话都会有一个超时时间，若服务器在超时时间内没有收到任何请求，则相应会话被视为过期（这段时间内如果连回来了仍视为有效）。一旦会话过期，就无法再重新打开，且任何与该会话相关的临时 ZNode 都会被删除

4.1.2.5 ACL（Access Control Lists）

ZooKeeper 采用 ACL策略来进行权限控制。Zk定义了5种权限，每个 ZNode 创建时都会带有一个 ACL 列表，用于决定谁可以对它执行何种操作

CREATE：允许创建其子节点
READ：允许从节点获取数据并列出其子节点
WRITE：允许为节点设置数据
DELETE：允许删除其子节点
ADMIN：允许为节点设置权限

ACL 依赖于 ZooKeeper 的客户端认证机制。ZooKeeper 提供了以下几种认证方式

digest：用户名和密码来识别客户端
sasl：通过 kerberos 来识别客户端
ip：通过 IP 来识别客户端

4.1.2.6 Watcher(事件监听器)

Watcher(事件监听器)是Zk的一个重要特性。Zk允许用户在指定ZNode上注册一些Watcher，并在特定事件触发时，Zk服务端会将事件通知到注册的客户端。该机制是Zk实现分布式协调服务的重要特性。

4.2 ZAB协议

全称Zookeeper Atomic Broadcast(原子消息广播协议)，与Paxos算法类似。比较复杂，不赘述。

第七章 Zookeeper技术内幕

7.1 系统模型

7.1.1 数据模型

树：ZooKeeper 的数据模型是一个树形结构的文件系统（ZNode Tree），树中的节点被称为 ZNode，每个节点上都可以保存数据，并挂上子节点
事务ID
- 在Zk中，事务是指能改变服务器状态的操作。包括节点创建，节点删除，节点内容更新，客户端会话创建，客户端会话失效
- 对于每一个事务请求，Zk会为其分配一个全局事务ID，用ZXID表示，通常是64位数字。每一个ZXID对应一次更新操作，可以根据值识别出各个操作的执行顺序

7.1.2 节点特性

7.1.2.1 节点分类

在Zk中，节点类型可以分为三类：持久节点(P)，临时节点(E)，顺序节点(S)节点有以下特性

节点特性	备注	默认
持久(P) / 临时(S)	必选，二选一	持久(P)
顺序(S)	是 / 否	非顺序

具体在节点的创建过程中，通过组合使用，可以生成以下四种组合型节点类型

持久节点(Persistent)：被创建后一直存在于服务器上，直至被删除操作主动清除。最常见的节点。
持久顺序节点(Persistent_Sequential)：在创建节点时可以设置这个标记，则每个父节点会维护子节点的先后顺序。即在创建过程中，自动为节点加上一个数字后缀，作为节点名，上限是Integer.MAX
临时节点(Ephemeral)：
- 临时节点的生命周期与客户端会话Session绑定在一起，会话失效，则节点被自动清理
- Zk规定了不能基于临时节点来创建子节点，即临时节点只能是叶子节点
临时顺序(Ephemeral_Sequential)：在临时节点的基础上，添加了顺序的特性

7.1.2.2 节点数据

节点的存储包含两部分

用户写入节点的数据内容
节点自身的一些状态信息，这些状态信息存在Stat的结构体中，包括事务ID、版本信息、子节点个数

7.1.3 版本——保证分布式数据原子性操作

Zk为数据节点引入了版本的概念，Zk中version的含义是：对数据节点的数据内容、子节点列表、节点ACL信息的修改次数
- 节点第一次创建时，version=0；对数据内容更变后，version=1
- 需要注意的是，即使前后的数据内容没变，version依然会变，version强调的是更变次数

每个节点状态中都有三类version，对节点的任何操作都会引起这三个版本号的变化
- version：当前数据节点数据内容的修改次数
- cversion：当前数据节点子节点的修改次数
- aversion：当前数据节点ACL更变的修改次数

设计version的意义：基于CAS乐观锁的思想进行更新
- 从源码来看，request里会带上请求的version，Zk服务端处理request时会校验version
  - request中的version=-1：表示客户端不要求使用乐观锁，因此会忽略版本对比；
  - request中的version!=-1：表示客户端要基于乐观锁更新
    - Zk服务端会比较请求的version和当前节点的currentVersion，一致则更新，不一致就抛异常

7.1.4 Watcher——数据更变的通知

在Zk中，引入了Watcher来实现分布式数据的发布/订阅功能，整体通知如下
- ①客户端向Zk服务器注册Watcher，并将Watcher存储在自身的WatcherManager中
- ②Zk服务器触发Watcher事件后，向客户端发送通知
- ③客户端线程从WatcherManager中取出对应的Watcher对象，执行回调逻辑

整体代码与逻辑：TODO
Watcher特性总结如下
- 一次性：一旦一个Watcher被触发，Zk会将其移除。因此开发者需要反复注册。这种设计有利于减轻服务端压力
- 客户端串行执行：客户端Watcher回调是一个串行同步的过程，因此保证了顺序
- 轻量：Watcher通知非常轻量，只会告诉客户端发生了某种事件，不会传达事件详情。这点需要客户端收到事件后主动重新拉取。有利于网络和内存开销

7.1.5 ACL——保障数据的安全

ACL的重要性：通过ACL(Access Control List)权限控制机制保障数据的安全

ACL介绍：可以从三方面理解该机制：权限模式(Scheme)，授权对象(ID)，权限(Permission)，通常使用 "scheme:id:permission" 来标识一个有效的ACL信息

权限模式(Scheme)：权限验证过程中使用哪个策略，开发人员使用最多的是以下四种权限
- IP：针对IP地址维度进行控制
  - 例1："ip:192.168.0.110"：表示控制权限只针对这个IP
  - 例2："ip:192.168.0.1/24"：表示针对192.168.0.*这个IP段进行权限控制
- Digest：最常用的，类似于"username:password"的形式
  - Zk会对其进行编码，将这种形式编码成无法辨识的字符串，避免明文
- World：开放者模式，不校验权限，权限对所有用户开放
  - 可以看作是特殊的Digest模式，即"world:anyone"
- Super：也是一种特殊的Digest模式，相当于管理员(超级用户)模式，超级用户可以操作所有节点
授权对象(ID)：与上述的权限模式配合使用。在不同的scheme下，id是不同的。见下图
权限(Permission)：权限就是通过了权限检查后可以被允许执行的操作。在Zk中操作可分以下5类
- CREATE：允许授权对象创建该节点的子节点
- READ：允许授权对象从该节点读取数据或子节点列表等
- WRITE：允许授权对象对该节点进行更新操作
- DELETE：允许授权对象删除该节点的子节点
- ADMIN：允许授权对象为该节点设置ACL权限

ACL的管理

ACL设置：在Zk服务端有两种方式能对ACL进行设置

方式	例子
方式一：创建节点的同时设置ACL参数，命令格式如下：【create [-s] [-e] path data acl】
方式二：通过setAcl命令，单独对已存在的节点进行设置：【setAcl path acl】