终于找到了最新版的Zookeeper入门级教程，建议收藏！

1、分布式一致性

1、CAP 理论

CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
• 可用性： 每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
• 分区容错性： 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eureka 实现的是 AP。

image-20231214151837817

zookeeper 是强一致性吗？

ZooKeeper 的一致性并不是强一致性，而是最终一致性。在 ZooKeeper 集群中，每个节点都有可能成为 leader 节点，负责处理客户端的请求和维护集群状态。ZooKeeper 采用的选举算法是基于 Paxos 的 ZAB（ZooKeeper Atomic Broadcast）协议。 在 ZAB 协议中，ZooKeeper 服务器分为两类：leader 和 follower。Leader 负责处理客户端的请求并维护 ZooKeeper 的状态

2、BASE 理论

BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。

• 基本可用： 在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。
• 软状态： 允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。
• 最终一致性： data replications 经过一段时间达到一致性。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

强一致性: 又称线性一致性(linearizability )

1.任意时刻，所有节点中的数据是一样的,

2.一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务

3.保证了强一致性，务必会损耗可用性

弱一致性:

1.系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。

2.即使过了不一致时间窗口，后续的读取也不一定能保证一致。

最终一致性:

1.弱一致性的特殊形式, 不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化

2.存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值

顺序一致性:

1.任何一次读都能读到某个数据的最近一次写的数据。

2.对其他节点之前的修改是可见(已同步)且确定的, 并且新的写入建立在已经达成同步的基础上

针对上面的思考题：Zookeeper 写入是强一致性, 读取是顺序一致性。

2、Zookeeper 入门与实战

1、Zookeeper 介绍

官方解释

ZooKeeper 是一个集中式服务，用于维护配置信息、命名、提供分布式同步、提供组服务。所有这些类型的服务都以某种形式由分布式应用程序使用。每次实施它们时，都需要进行大量工作来修复不可避免的错误和竞争条件。由于实现此类服务很困难，应用程序最初通常会忽略它们，这使得它们在发生变化时变得脆弱并且难以管理。即使正确完成，这些服务的不同实现也会导致部署应用程序时的管理复杂性。

通俗来说，ZooKeeper 是一个开源的分布式协调框架，是 Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

官方：https://zookeeper.apache.org/

ZooKeeper 本质上是一个分布式的小文件存储系统（Zookeeper = 文件系统+监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

Zookeeper 从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应。

2、设计目标

ZooKeeper 很简单。 ZooKeeper 允许分布式进程通过共享的分层命名空间相互协调，该命名空间的组织方式与标准文件系统类似。命名空间由数据寄存器（用 ZooKeeper 的说法称为 znode）组成，它们类似于文件和目录。与专为存储而设计的典型文件系统不同，ZooKeeper 数据保存在内存中，这意味着 ZooKeeper 可以实现高吞吐量和低延迟数。

ZooKeeper 的实现非常注重高性能、高可用性、严格有序的访问。ZooKeeper 的性能方面意味着它可以在大型分布式系统中使用。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。

ZooKeeper 被复制。 与它协调的分布式进程一样，ZooKeeper 本身旨在通过一组称为集合的主机进行复制。

动物园管理员服务

组成 ZooKeeper 服务的服务器必须相互了解。它们在内存中维护状态映像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper 服务就可用。

客户端连接到单个 ZooKeeper 服务器。客户端维护一个 TCP 连接，通过该连接发送请求、获取响应、获取监视事件并发送心跳。如果与服务器的 TCP 连接中断，客户端将连接到另一台服务器。

ZooKeeper 已订购。 ZooKeeper 用反映所有 ZooKeeper 事务顺序的数字标记每个更新。后续操作可以使用该顺序来实现更高级别的抽象，例如同步原语。

ZooKeeper 速度很快。 它在“读取为主”的工作负载中尤其快。ZooKeeper 应用程序在数千台计算机上运行，并且在读取比写入更常见的情况下性能最佳（比率约为 10: 1）。

3、Zookeeper 安装

1、Linux 安装

下载地址：https://zookeeper.apache.org/releases.html

运行环境：jdk8

image-20231214153331176

上传到 Linux 的目录

解压

tar -zvxf apache-zookeeper-3.8.3-bin.tar.gz

进入 conf 目录，复制 zoo_sample.cfg，修改为 zoo.cfg

image-20231214160731190

修改配置文件，修改 zoo.cfg 配置文件，将 dataDir =/tmp/zookeeper 修改为指定的 data 目录

zoo.cfg 中参数含义：

启动 zookeeper server

• 使用脚本启动 # 可以通过 bin/zkServer.sh 来查看都支持哪些参数 # 默认加载配置路径conf/zoo.cfg bin/zkServer.sh start conf/zoo.cfg # 查看zookeeper状态 bin/zkServer.sh status
• 使用命令启动 进入 bin 目录，执行命令：./zkServer.sh

启动 zookeeper client 连接 Zookeeper server

• 使用脚本启动 bin/zkCli.sh # 连接远程的zookeeper server bin/zkCli.sh -server ip:port
• 命令连接：zkCli.sh -server ip:port

连接成功后，你会看到

image-20231214170149547

4、命令操作

1、客户端操作

输入命令 help 查看 zookeeper 支持的所有命令：

image-20231214170333504

查询日志信息

./zkServer.sh start-foreground

查询服务端状态

./zkServer.sh status

2、常见服务端命令

https://zookeeper.apache.org/doc/r3.8.3/zookeeperCLI.html

3、数据结构

ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。

image-20231214170632941

ZooKeeper 的数据模型是层次模型，层次模型常见于文件系统。层次模型和 key-value 模型是两种主流的数据模型。ZooKeeper 使用文件系统模型主要基于以下两点考虑:

1. 文件系统的树形结构便于表达数据之间的层次关系
2. 文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )

ZooKeeper 的层次模型称作 Data Tree，Data Tree 的每个节点叫作 Znode。不同于文件系统，每个节点都可以保存数据，每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从 0 开始计数。

public class DataTree {
    private final ConcurrentHashMap<String, DataNode> nodes =
        new ConcurrentHashMap<String, DataNode>();
        
        
    private final WatchManager dataWatches = new WatchManager();
    private final WatchManager childWatches = new WatchManager();
    
}
 
public class DataNode implements Record {
    byte data[];
    Long acl;
    public StatPersisted stat;
    private Set<String> children = null;
 }  

1、节点分类

一个 znode 可以使持久性的，也可以是临时性的:

1. 持久节点(PERSISTENT): 这样的 znode 在创建之后即使发生 ZooKeeper 集群宕机或者 client 宕机也不会丢失。
2. 临时节点(EPHEMERAL ): client 宕机或者 client 在指定的 timeout 时间内没有给 ZooKeeper 集群发消息，这样的 znode 就会消失。

如果上面两种 znode 具备顺序性，又有以下两种 znode :

1. 持久顺序节点(PERSISTENT_SEQUENTIAL): znode 除了具备持久性 znode 的特点之外，znode 的名字具备顺序性。
2. 临时顺序节点(EPHEMERAL_SEQUENTIAL): znode 除了具备临时性 znode 的特点之外，zorde 的名字具备顺序性。

zookeeper 主要用到的是以上 4 种节点。

Container 节点 (3.5.3 版本新增)：Container 容器节点，当容器中没有任何子节点，该容器节点会被 zk 定期删除（定时任务默认 60s 检查一次)。 和持久节点的区别是 ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为 0 时，会自动删除该节点。可以用于 leader 或者锁的场景中。

TTL 节点: 带过期时间节点，默认禁用，需要在 zoo.cfg 中添加 extendedTypesEnabled = true 开启。 注意：ttl 不能用于临时节点

#创建持久节点
create /servers  xxx
#创建临时节点
create -e /servers/host  xxx
#创建临时有序节点
create -e -s /servers/host  xxx
#创建容器节点
create -c /container xxx
# 创建ttl节点
create -t 10 /ttl

2、节点状态信息

image-20231215130835335

• cZxid ：Znode 创建的事务 id。
• ctime：节点创建时的时间戳。
• mZxid ：Znode 被修改的事务 id，即每次对 znode 的修改都会更新 mZxid。

对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeper Transaction Id），通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1 小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。

• pZxid: 表示该节点的子节点列表最后一次修改的事务 ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该 ID（注意: 只有子节点列表变更了才会变更 pzxid，子节点内容变更不会影响 pzxid）
• mtime：节点最新一次更新发生时的时间戳.
• cversion ：子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。
• dataVersion：数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
• ephemeralOwner: 如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 session id。如果不是, ephemeralOwner 值为 0(持久节点)。

在 client 和 server 通信之前, 首先需要建立连接, 该连接称为 session。连接建立后, 如果发生连接超时、授权失败, 或者显式关闭连接, 连接便处于 closed 状态, 此时 session 结束。

• dataLength ： 数据的长度
• numChildren ：子节点的数量（只统计直接子节点的数量）

3、监听通知（watcher）机制

• 一个 Watch 事件是一个一次性的触发器，当被设置了 Watch 的数据发生了改变的时候，则服务器将这个改变发送给设置了 Watch 的客户端，以便通知它们。 举例说明：

1. 同时开启两个服务端，一个服务端监听/zk 节点，另一个断开连接
2. 会出现第一个红框的内容，也就是监听已经触发了
3. 此时再次创建节点时，会发现没有监听到，也就是第二个红框
4. 使用监听命令后，再次创建节点，创建的节点就被监听到了，这就是 一个 Watch 事件是一个一次性的触发器

• Zookeeper 采用了 Watcher 机制实现数据的发布订阅功能**，多个订阅者可同时监听某一特定主题对象，当该主题对象的自身状态发生变化时例如节点内容改变、节点下的子节点列表改变等，会实时、主动通知所有订阅者。
• watcher 机制事件上与观察者模式类似，也可看作是一种观察者模式在分布式场景下的实现方式。

watcher 的过程：

1. 客户端向服务端注册 watcher
2. 服务端事件发生触发 watcher
3. 客户端回调 watcher 得到触发事件情况

注意：Zookeeper 中的 watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

支持的事件类型：

• None: 连接建立事件
• NodeCreated： 节点创建
• NodeDeleted： 节点删除
• NodeDataChanged：节点数据变化
• NodeChildrenChanged：子节点列表变化
• DataWatchRemoved：节点监听被移除
• ChildWatchRemoved：子节点监听被移除

当节点开启监听 ls -w path 后，就可以看到节点发生的事件

#监听节点数据的变化
get -w path 
stat -w path
#监听子节点增减的变化 
ls -w path 

4、使用场景

1、协同服务

设计一个 master-worker 的组成员管理系统，要求系统中只能有一个 master , master 能实时获取系统中 worker 的情况。保证组里面只有一个 master 的设计思路

#master1
create -e /master "m1:2223"  
 
#master2
create -e /master "m2:2223"   # /master已经存在，创建失败
Node already exists: /master
#监听/master节点
stat -w /master
#当master2收到/master节点删除通知后可以再次发起创建节点操作
create -e /master "m2:2223" 

master-slave 选举也可以用这种方式

image-20231215132959738

master 监控 worker 状态的设计思路

#master服务
create /workers
#让master服务监控/workers下的子节点
ls -w /workers
 
#worker1
create -e /workers/w1 "w1:2224" #创建子节点，master服务会收到子节点变化通知
 
#master服务
ls -w /workers
#worker2
create -e /workers/w2 "w2:2224"  #创建子节点，master服务会收到子节点变化通知
 
#master服务
ls -w /workers
#worker2
quit  #worker2退出，master服务会收到子节点变化通知

2、条件更新

设想用 2 /c 实现一个 counter，使用 set 命令来实现自增 1 操作。条件更新场景∶

1. 客户端 1 把/c 更新到版本 1，实现/c 的自增 1。
2. 客户端 2 把/c 更新到版本 2，实现/c 的自增 1。
3. 客户端 1 不知道/c 已经被客户端⒉更新过了，还用过时的版本 1 是去更新/c，更新失败。如果客户端 1 使用的是无条件更新，/c 就会更新为 2，没有实现自增 1。

使用条件更新可以避免出现客户端基于过期的数据进行数据更新的操作。

5、总结

1. 同一级节点 key 名称是唯一的

image-20231215134051417已存在/lock 节点，再次创建会提示已经存在

1. 创建节点时，必须要带上全路径
2. session 关闭，临时节点清除
3. 自动创建顺序节点

image-20231215134123473

1. watch 机制，监听节点变化 事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
2. delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除。

6、应用场景

ZooKeeper 适用于存储和协同相关的关键数据，不适合用于大数据量存储。有了上述众多节点特性，使得 zookeeper 能开发不出不同的经典应用场景，比如：

• 注册中心
• 数据发布/订阅（常用于实现配置中心）
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master 选举
• 分布式锁
• 分布式队列

1、统一命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。

例如：IP 不容易记住，而域名容易记住。

利用 ZooKeeper 顺序节点的特性，制作分布式的序列号生成器，或者叫 id 生成器。（分布式环境下使用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。

/
└── /order
    ├── /order-date1-000000000000001
    ├── /order-date2-000000000000002
    ├── /order-date3-000000000000003
    ├── /order-date4-000000000000004
    └── /order-date5-000000000000005

2、数据发布/订阅

数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点:

1. 数据量小的 KV
2. 数据内容在运行时会发生动态变化
3. 集群机器共享，配置一致

ZooKeeper 采用的是推拉结合的方式。

1. 推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知
2. 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

3、统一集群管理

分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。

ZooKeeper 可以实现实时监控节点状态变化：

• 可将节点信息写入 ZooKeeper 上的一个 ZNode。
• 监听这个 ZNode 可获取它的实时状态变化。

4、负载均衡

在 Zookeeper 中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

补充知识点：

永久性 Watch

在被触发之后，仍然保留，可以继续监听 ZNode 上的变更，是 Zookeeper 3.6.0 版本新增的功能

addWatch [-m mode] path

addWatch 的作用是针对指定节点添加事件监听，支持两种模式

• PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
• PERSISTENT_RECURSIVE，持久化递归订阅，在 PERSISTENT 的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）

4、ACL 权限控制

zookeeper 的 ACL（Access Control List，访问控制表）权限在生产环境是特别重要的，ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。

1、ACL 构成

zookeeper 的 acl 通过 [scheme:id:permissions] 来构成权限列表。

• scheme：授权的模式，代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。
• id：授权对象，代表允许访问的用户。如果我们选择采用 IP 方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则对应于一个用户名。如果是 World 模式，是授权系统中所有的用户。
• permissions：授权的权限，权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限， 创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。

image-20231215140419491

取消节点的读权限后，读取/javaxiaobear节点没有权限，重新授权后，又可以读取了

2、auth授权模式

1、创建用户

addauth digest javaxiaobear:123456

2、设置权限

etAcl /name auth:javaxiaobear:123456:cdrwa
 
# 加密
echo -n javaxiaobear:123456 | openssl dgst -binary -sha1 | openssl base64
setAcl /name auth:javaxiaobear:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa

3、digest授权模式

#设置权限
setAcl /tuling/fox digest:fox:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa

4、IP授权模式

setAcl /node-ip ip:192.168.109.128:cdwra
create /node-ip  data  ip:192.168.109.128:cdwra

多个指定IP可以通过逗号分隔， 如 setAcl /node-ip ip:IP1:rw,ip:IP2:a

5、Super 超级管理员模式

这是一种特殊的Digest模式， 在Super模式下超级管理员用户可以对Zookeeper上的节点进行任何的操作。

需要在启动脚本上通过添加JVM 参数开启：

DigestAuthenticationProvider中定义
-Dzookeeper.DigestAuthenticationProvider.superDigest=admin:<base64encoded(SHA1(123456))