> For the complete documentation index, see [llms.txt](https://yangsx95.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yangsx95.gitbook.io/notes/distributed/fen-bu-shi-xie-tiao/zookeeper.md).

# Zookeeper

[Zookeeper](http://zookeeper.apache.org) 是开源的分布式协调服务，它提供了一些简单的原语。应用程序可以基于这些原语实现一些复杂的高级服务。

不同于Redis的KV结构，zk的数据结构是一个类似目录树的结构：

![ZooKeeper's Hierarchical Namespace](/files/QvXqYgzdIlGEL4gKpCHP)

1. 层级结构中的每个节点称为 `znode`，每个节点都可以存储数据，但是最大数据存储大小为`1MB`。
2. 他们统一存储在内存中（高性能、低延迟、高可用）。
3. 存储的内容同Redis相同，也是二进制安全的，也就是说zk不关心他们的数据编码格式，给什么byte流就存储什么byte流。
4. 为了保证zk快速、高可用的特点，不可以将zk当作数据库使用，这也是为什么每个znode只能存储1MB大小的原因。

每个Client在连接zk集群时，都会产生一个Session，代表当前的会话，依托于Session，可以将znode分为一下几种类型：

1. 持久节点
2. 临时节点，会话级别，会话不存在数据就会消失。Session消失通过事件通知删除节点，典型的应用场景为分布式锁（可以有效的避免死锁的问题，因为应用程序一旦结束会话也会结束，锁也会被释放）
3. 序列节点

Zookeeper 通常也作为一个集群使用：

![ZooKeeper Service](/files/CEudFUae6A1ICsa3ROIh)

1. zk集群是一种主从复制集群（Redis Cluster是一种数据分片集群），主从复制集群中的每个Server的数据都是完全相同的，且主节点用作写操作，从节点用来扩展读操作
2. 在集群中分为两种角色：`Leader`和`Follower`，`Leader`写、`Follower`读
3. 当Client对`Follower`发生写操作，会将写操作重定向给`Leader`

Zookeeper集群还是一个可以快速自我修复的集群环境：

1. 主从复制集群的主要问题是`Leader`节点的单点故障问题
2. 当zk的Leader发生故障后，zk集群会进入无主模型，zk会拒绝所有的请求，此时集群处于不可用状态
3. 此时zk内部多个`Follower`会发生选举，重新选举出一个Leader（这个过程只有不到200ms，并可以立即处理请求，并恢复原来的吞吐量）
4. 选举成功后，zk变为可用状态，并开始处理客户端请求

Zookeeper集群的读写性能也是极高的（横坐标为客户端读写的占比，纵坐标为每秒请求数）：

![ZooKeeper Throughput as the Read-Write Ratio Varies](/files/yj9lBGfbDWFkErRx1PdJ)

Zookeeper同时具有以下特性：

1. 顺序一致性：因为时主从模型，写操作只有一个Leader节点
2. 原子性：操作一个znode，集群中的所有Server要么都操作成功，要不都不成功（强一致性写入会导致不可用性，故采用最终一致性，也就是过半写入）
3. 统一视图：主从复制模型，连任何一个集群节点都可以看到所有的完整的数据（包括session，也就是说是session共享的）
4. 持久性：zk的数据存储在内存中，同redis相同他也有持久化策略
5. 实时性：在时间范围内是最新的数据

## 使用zk

```shell
# zkCli.sh

# 查看根路径下的znode
[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]


# 创建一个znode，但是不指定值，那么他的值为 null
[zk: localhost:2181(CONNECTED) 1] create  /test1
Created /test1
[zk: localhost:2181(CONNECTED) 2] get /test1
null


# 创建一个znode，指定值
[zk: localhost:2181(CONNECTED) 3] create /test2 "test2"
Created /test2
[zk: localhost:2181(CONNECTED) 4] get /test2
test2


[zk: localhost:2181(CONNECTED) 5] ls /
[test1, test2, zookeeper]


# 已经存在的znode，不能被再次创建
[zk: localhost:2181(CONNECTED) 6] create /test2
Node already exists: /test2

# 使用get -s 查看znode的状态信息
[zk: localhost:2181(CONNECTED) 7] get -s /test2
test2
# zk是顺序执行的，因为Leader是一个单机只负责写入，所以通过Leader内部的自增ID来实现顺序执行的
# 这个顺序ID就是Zxid，代表zk的事务ID，其中c代表create创建操作
# cZxid的值是一个16进制数，前32位代表Leader纪元（每个Leader上任都是一个新的纪元），后32位代表事务在该纪元的递增ID
# 0x100000003 的纪元是1，事务ID为3
cZxid = 0x100000003
# 创建事务的时间
ctime = Thu Mar 24 03:11:13 UTC 2022
# 修改事务的事务id
mZxid = 0x100000003
# 修改事务的时间
mtime = Thu Mar 24 03:11:13 UTC 2022
# 当前节点下创建的最后子节点的节点号，如果没有子节点，那么这个值就是他本身
pZxid = 0x100000003
cversion = 0
dataVersion = 0
aclVersion = 0
# 节点所属的sessionID，如果是持久化节点，值为0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0


# 使用-e参数创建临时节点，临时节点的生命周期依托与session
[zk: localhost:2181(CONNECTED) 8] create -e /test3 "test3"
Created /test3
[zk: localhost:2181(CONNECTED) 9] get -s /test3
test3
cZxid = 0x100000005
ctime = Thu Mar 24 03:29:32 UTC 2022
mZxid = 0x100000005
mtime = Thu Mar 24 03:29:32 UTC 2022
pZxid = 0x100000005
cversion = 0
dataVersion = 0
aclVersion = 0
# 这里可以看到依托的session的ID
# 注意，连接session、断开session也会消耗事务id
ephemeralOwner = 0x300038d66c80000
dataLength = 5
numChildren = 0


# 在某个节点下创建子节点
[zk: localhost:2181(CONNECTED) 10] create /test1/a ""
Created /test1/a
[zk: localhost:2181(CONNECTED) 11] create /test1/b ""
Created /test1/b
[zk: localhost:2181(CONNECTED) 12] ls /test1
[a, b]
[zk: localhost:2181(CONNECTED) 13] get -s /test1/b
cZxid = 0x100000007
....
[zk: localhost:2181(CONNECTED) 14] get -s /test1
null
...
pZxid = 0x100000007 # 可以看到pZxid的值为最近一个添加的子节点的创建事务ID
...


# 创建序列节点，有序节点是会自动更改节点名称加上序列的节点
# 执行create后，将会返回节点的名称，需要程序自己记录这个名称，后续操作都要使用这个节点处理
# 因为会自动添加序列，所以有序节点可以创建多个
[zk: localhost:2181(CONNECTED) 19] create -s /test4
Created /test40000000003
[zk: localhost:2181(CONNECTED) 20] create -s /test4
Created /test40000000004
# zk内部会维护指定节点的序列，如果将所有的/test4序列节点删除，再次创建，他的序列不会重新开始
[zk: localhost:2181(CONNECTED) 29] delete /test40000000003
[zk: localhost:2181(CONNECTED) 30] delete /test40000000004
[zk: localhost:2181(CONNECTED) 31] create -s /test4
Created /test40000000005


# 使用 set 命令修改值
[zk: localhost:2181(CONNECTED) 32] set /test1 "aaa"
[zk: localhost:2181(CONNECTED) 33] get -s /test1
aaa
cZxid = 0x100000002    # 创建事务ID不变
ctime = Thu Mar 24 03:09:10 UTC 2022
mZxid = 0x10000000f    # 修改事务ID发生了变化
mtime = Thu Mar 24 06:03:37 UTC 2022
....
```

## 应用场景

### 同步（分布式锁）

相比较于Redis，zk实现分布式锁：

1. zk具有统一视图，其一致性相比于Redis要好得多
2. 锁的释放与死锁的判断可以通过基于session的临时节点，相比与Redis的方式（主动轮询）
   1. 基本没有什么延迟
   2. 如果等待锁的客户端较多，每次心跳将会给redis带来很大的压力
3. zk锁在释放时会回调所有的客户端，将会造成太大的压力
   1. 可以使用`序列节点+watch`是新公平锁，减少回调的客户端
   2. 注意，每个等待的客户端都去watch前一个锁（像一个链表）

分布式锁的实现：

1. 使用create命令添加一个znode，其名称为分布式锁的唯一标志
2. 当有一把锁存在时，其他进程使用create加锁会失败
3. 为了保证不出现死锁的情况，Redis会加上过期时间处理，但是zk不需要设置国企时间，只要保证这个节点的类型是临时节点即可。当应用程序的逻辑完成会自动结束会话，这时会自动释放锁。

分布式公平锁（队列式的锁）：

1. 首先创建锁的根节点
2. 每当有个进程需要加锁时，会在根节点下创建一个有序的临时节点 `create -e -s`
3. 进程加锁完毕后，会使用`ls`命令查询刚刚创建的有序节点是否在子节点中序列最小，如果最小，说明获取到了锁

### 分布式配置（配置中心/注册中心）

![image-20220327184019860](/files/oIDK4wVwq93AU0QrS2JW)

配置中心：

1. 将配置数据放置在znode节点中，使用目录结构对配置分类，znode的值存储配置内容（注意最多只有1MB大小）
2. 配置使用方**watch**目标配置znode，当配置发生变更时，通过事件`NodeDataChanged`可以保证客户端可以实时更新配置内容

注册中心：

1. 所有的应用程序启动会将其注册到一个znode的子节点下
2. 所有的应用程序watch该znode，当znode的children发生变更时，会触发`NodeChildrenChanged`事件，来通知注册中心的其他程序该服务的上线、下线的情况

## 集群

### 集群角色

一台zookeeper一般无法满足需求，通常都会对zookeeper集群

*参考：<https://blog.csdn.net/fu123123fu/article/details/81193780>*

1. Leader：
   * 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
   * 集群内部各服务器的调度者
2. Follower：
   * 处理客户端非事务请求、**转发事务请求给Leader**
   * 参与事务请求Proposal 的投票（Leader 发起的提案，要求 Follower 投票，需要半数以上follower节点通过，leader才会commit数据）
   * 参与Leader的投票选举
3. Observer：
   * 观察者，不参与任何投票
   * 其余部分与Follower一致
   * 用于保证高可用，避免集群节点多，投票延时大的问题
   * 增加observer不影响集群中事务处理能力，同时还能提高集群非事务处理能力

> 一个zookeeper集群要对外提供服务，必须要保证过半的机器正常工作并且彼此之间能够正常通信。

### 集群搭建注意事项

如果要搭建一个能够允许F台机器down掉的集群，那么就要部署`2F+1`台服务器构成的 zookeeper 集群。因此3台机器构成的 zookeeper 集群，能够在挂掉1台机器后依然正常工作。一个5台机器集群的服务，能够对2台机器挂掉的情况下进行容灾。如果一个由6台服务器构成的集群，同样只能挂掉2台机器。因此，5台和6台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的server会选举出一台server为 Leader，其它的就作为 follower（这里不考虑 observer 角色）。

### 集群特性

Zookeeper集群具有以下特性：

1. 扩展性：主要通过三个方面体现
   1. 集群角色分为 Leader、Follower、Observer，增加Follower和Observer可以扩展读能力，增加Observer在扩展读能力的情况下，不会影响zk的选举效率
   2. 采用读写分离的方式，且是一个主从复制集群，容易进行横向扩展
   3. 扩展方式通过修改配置文件即可
2. 可靠性：攘其外必先安其内
   1. 攘其外：具有最终一致性
   2. 安其内：当zk集群出现问题时，可以快速进行自我修复，在修复过程中集群会变为不可用状态，恢复之后再提供服务

zk基于分布式算法ZAB，参见文章`分布式一致性算法`。

## watch机制

watch机制是zk的核心。

![img](/files/PwcN3op2pD6AGarJTIs5)

1. 客户端1通过watch命令监控某个节点
2. 客户端2对节点进行一些操作，当发生操作后，客户端1会接受到一个事件通知
3. 事件分为如下几个类型：
   1. NodeCreated
   2. NodeDeleted
   3. NodeDataChanged
   4. NodeChildrenChanged
   5. None，客户端与Zookeeper断开连接