Zookeeper

Zookeeper 是开源的分布式协调服务，它提供了一些简单的原语。应用程序可以基于这些原语实现一些复杂的高级服务。

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

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

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

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

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

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

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

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

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

Zookeeper同时具有以下特性：

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

使用zk

# 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实现分布式锁：

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

分布式锁的实现：

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

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

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

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

配置中心：

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

注册中心：

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

集群

集群角色

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

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

Leader：
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
- 集群内部各服务器的调度者
Follower：
- 处理客户端非事务请求、转发事务请求给Leader
- 参与事务请求Proposal 的投票（Leader 发起的提案，要求 Follower 投票，需要半数以上follower节点通过，leader才会commit数据）
- 参与Leader的投票选举
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. 集群角色分为 Leader、Follower、Observer，增加Follower和Observer可以扩展读能力，增加Observer在扩展读能力的情况下，不会影响zk的选举效率
2. 采用读写分离的方式，且是一个主从复制集群，容易进行横向扩展
3. 扩展方式通过修改配置文件即可
可靠性：攘其外必先安其内
1. 攘其外：具有最终一致性
2. 安其内：当zk集群出现问题时，可以快速进行自我修复，在修复过程中集群会变为不可用状态，恢复之后再提供服务

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

watch机制

watch机制是zk的核心。

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

最后更新于5个月前