Zookeeper原理-CSDN博客

本文链接：https://blog.csdn.net/chuixue24/article/details/123868921

在了解Zookeeper之前，需要对分布式相关知识有一定了解，什么是分布式系统呢？

通常情况下，单个物理节点很容易达到性能，计算或者容量的瓶颈，所以这个时候就需要多个物理节点来共同完成某项任务，一个分布式系统的本质是分布在不同网络或计算机上的程序组件，彼此通过信息传递来协同工作的系统，而Zookeeper正是一个分布式应用协调框架，在分布式系统架构中有广泛的应用场景。

1. 什么是Zookeeper？

官方文档上这么解释zookeeper，它是一个分布式协调框架，是Apache Hadoop 的一个子项
目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同
步服务、集群管理、分布式应用配置项的管理等。

2. Zookeeper 核心概念

上面的解释有点抽象，暂时可以理解为 Zookeeper 是一个用于存储少量数据的基于内存的数据库，主要有如下两个核心的概念：文件系统数据结构+监听通知机制。

2.1、文件系统数据结构

Zookeeper维护一个类似文件系统的数据结构：

每个子目录项都被称作为 znode(目录节点)，和文件系统类似，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode。
有四种类型的znode：

1、PERSISTENT

持久化目录节点：客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他将永远存在。

2、 PERSISTENT_SEQUENTIAL

持久化顺序编号目录节点：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号。

3、EPHEMERAL

临时目录节点：客户端与zookeeper断开连接后，该节点被删除。

4、EPHEMERAL_SEQUENTIAL

临时顺序编号目录节点：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号。

5. Container 节点

3.5.3 版本新增，如果Container节点下面没有子节点，则Container节点在未来会被Zookeeper自动清除,定时任务默认60s 检查一次。

6. TTL 节点

默认禁用，只能通过系统配置 zookeeper.extendedTypesEnabled=true 开启，不稳定。

2.2、监听通知机制

客户端注册监听它关心的任意节点，或者目录节点及递归子目录节点。
1. 如果注册的是对某个节点的监听，则当这个节点被删除，或者被修改时，对应的客户端将被通
知。
2. 如果注册的是对某个目录的监听，则当这个目录有子节点被创建，或者有子节点被删除，对应
的客户端将被通知。
3. 如果注册的是对某个目录的递归子节点进行监听，则当这个目录下面的任意子节点有目录结构
的变化（有子节点被创建，或被删除）或者根节点有数据变化时，对应的客户端将被通知。
注意：所有的通知都是一次性的，及无论是对节点还是对目录进行的监听，一旦触发，对应的监
听即被移除。递归子节点，监听是对所有子节点的，所以，每个子节点下面的事件同样只会被触
发一次。

2.3、Zookeeper 经典的应用场景

1. 分布式配置中心
2. 分布式注册中心
3. 分布式锁
4. 分布式队列
5. 集群选举
6. 分布式屏障
7. 发布/订阅

可以参考：Zookeeper典型使用场景_chuixue24的博客-CSDN博客1. Zookeeper 非公平锁/公平锁/共享锁 2. Leader 选举在分布式场景中的应用 3. Spring Cloud Zookeeper注册中心Zookeeper分布式锁Zookeeper 分布式锁加锁原理如上实现方式在并发问题比较严重的情况下，性能会下降的比较厉害，主要原因是，所有的连接都在对同一个节点进行监听，当服务器检测到删除事件时，要通知所有的连接，所有的连接同时收到事件，再次并发竞争，这就是羊群效应。这种加锁方式是非公平锁的具体实现：如何避免https://blog.csdn.net/chuixue24/article/details/121077925

3. Zookeeper 的 ACL 权限控制( Access Control List )

Zookeeper 的ACL 权限控制,可以控制节点的读写操作,保证数据的安全性，Zookeeper ACL 权
限设置分为 3 部分组成，分别是：权限模式（Scheme）、授权对象（ID）、权限信息
（Permission）。最终组成一条例如“scheme:id:permission”格式的 ACL 请求信息。

下面我们具体看一下这 3 部分代表什么意思：

Scheme（权限模式）：用来设置 ZooKeeper 服务器进行权限验证的方式。

ZooKeeper 的权限验证方式大体分为两种类型：
一种是范围验证。所谓的范围验证就是说 ZooKeeper 可以针对一个 IP 或者一段 IP 地址授予某
种权限。比如我们可以让一个 IP 地址为“ip：192.168.0.110”的机器对服务器上的某个数据节
点具有写入的权限。或者也可以通过“ip:192.168.0.1/24”给一段 IP 地址的机器赋权。
另一种权限模式就是口令验证，也可以理解为用户名密码的方式。在 ZooKeeper 中这种验证方
式是 Digest 认证，而 Digest 这种认证方式首先在客户端传送“username:password”这种形
式的权限表示符后，ZooKeeper 服务端会对密码部分使用 SHA-1 和 BASE64 算法进行加密，
以保证安全性。
还有一种Super权限模式, Super可以认为是一种特殊的 Digest 认证。具有 Super 权限的客户端
可以对 ZooKeeper 上的任意数据节点进行任意操作。

授权对象（ID）

授权对象就是说我们要把权限赋予谁，而对应于 4 种不同的权限模式来说，如果我们选择采用 IP
方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则
对应于一个用户名。如果是 World 模式，是授权系统中所有的用户。

权限信息（Permission）

权限就是指我们可以在数据节点上执行的操作种类，如下所示：在 ZooKeeper 中已经定义好的
权限有 5 种：
数据节点（c: create）创建权限，授予权限的对象可以在数据节点下创建子节点；
数据节点（w: wirte）更新权限，授予权限的对象可以更新该数据节点；
数据节点（r: read）读取权限，授予权限的对象可以读取该节点的内容以及子节点的列表信息；
数据节点（d: delete）删除权限，授予权限的对象可以删除该数据节点的子节点；
数据节点（a: admin）管理者权限，授予权限的对象可以对该数据节点体进行 ACL 权限设置。

命令：
getAcl：获取某个节点的acl权限信息
setAcl：设置某个节点的acl权限信息
addauth: 输入认证授权信息，相当于注册用户信息，注册时输入明文密码，zk将以密文的形式存
储

可以通过系统参数zookeeper.skipACL=yes进行配置，默认是no,可以配置为true, 则配置过的
ACL将不再进行权限检测。

生成授权ID的两种方式:
a.代码生成ID:

 @Test
 public void generateSuperDigest() throws NoSuchAlgorithmException {
 String sId = DigestAuthenticationProvider.generateDigest("gj:test");
 System.out.println(sId);// gj:X/NSthOB0fD/OT6iilJ55WJVado=
 }

b.在xshell 中生成
1 echo ‐n <user>:<password> | openssl dgst ‐binary ‐sha1 | openssl base64

设置ACL有两种方式：

节点创建的同时设置ACL

create [-s] [-e] [-c] path [data] [acl]
create /zk‐node datatest digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa

或者用setAcl 设置

setAcl /zk‐node digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa

添加授权信息后，不能直接访问，直接访问将报如下异常

 get /zk‐node
 异常信息:
 org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth
for /zk‐node

访问前需要添加授权信息

addauth digest gj:test
get /zk‐node
datatest

另一种授权模式： auth 明文授权
使用之前需要先
addauth digest username:password 注册用户信息，后续可以直接用明文授权
如：

addauth digest u100:p100
create /node‐1 node1data auth:u100:p100:cdwra
这是u100用户授权信息会被zk保存，可以认为当前的授权用户为u100
get /node‐1
node1data

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
Super 超级管理员模式
这是一种特殊的Digest模式，在Super模式下超级管理员用户可以对Zookeeper上的节点进行任
何的操作。
需要在启动了上通过JVM 系统参数开启：

‐Dzookeeper.DigestAuthenticationProvider.superDigest=super:
<base64encoded(SHA1(password))

4. ZooKeeper 内存数据和持久化

Zookeeper数据的组织形式为一个类似文件系统的数据结构，而这些数据都是存储在内存中的，
所以我们可以认为，Zookeeper是一个基于内存的小型数据库。
内存中的数据：

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();

DataNode 是Zookeeper存储节点数据的最小单位：

public class DataNode implements Record {
 byte data[];
 Long acl;
 public StatPersisted stat;
 private Set<String> children = null;

5.事务日志

针对每一次客户端的事务操作，Zookeeper都会将他们记录到事务日志中，当然，Zookeeper也
会将数据变更应用到内存数据库中。我们可以在zookeeper的主配置文件zoo.cfg 中配置内存中
的数据持久化目录，也就是事务日志的存储路径 dataLogDir. 如果没有配置dataLogDir（非必
填）, 事务日志将存储到dataDir （必填项）目录。

zookeeper提供了格式化工具可以进行数据查看事务日志数据
org.apache.zookeeper.server.LogFormatter

java ‐classpath .:slf4j‐api‐1.7.25.jar:zookeeper‐3.5.8.jar:zookeeper‐jute‐
3.5.8.jar org.apache.zookeeper.server.LogFormatter /usr/local/zookeeper/apache‐zo
okeeper‐3.5.8‐bin/data/version‐2/log.1

如下是我本地的日志文件格式化效果

从左到右分别记录了操作时间，客户端会话ID，CXID,ZXID,操作类型，节点路径，节点数据（用
#+ascii 码表示），节点版本。

Zookeeper进行事务日志文件操作的时候会频繁进行磁盘IO操作，事务日志的不断追加写操作会触发底层磁盘IO为文件开辟新的磁盘块，即磁盘Seek。因此，为了提升磁盘IO的效率，
Zookeeper在创建事务日志文件的时候就进行文件空间的预分配- 即在创建文件的时候，就向操作系统申请一块大一点的磁盘块。这个预分配的磁盘大小可以通过系统参数
zookeeper.preAllocSize 进行配置。

事务日志文件名为： log.<当时最大事务ID>，应为日志文件时顺序写入的，所以这个最大事务
ID也将是整个事务日志文件中，最小的事务ID，日志满了即进行下一次事务日志文件的创建。

6.数据快照

数据快照用于记录Zookeeper服务器上某一时刻的全量数据，并将其写入到指定的磁盘文件中。
可以通过配置snapCount配置每间隔事务请求个数，生成快照，数据存储在dataDir 指定的目录
中，为了避免集群中所有机器在同一时间进行快照，实际的快照生成时机为事务数达到 [snapCount/2 + 随机数(随机数范围为1 ~ snapCount/2 )] 个数时开
始快照。

可以通过如下方式进行查看快照数据：

java ‐classpath .:slf4j‐api‐1.7.25.jar:zookeeper‐3.5.8.jar:zookeeper‐jute‐
3.5.8.jar org.apache.zookeeper.server.SnapshotFormatter /usr/local/zookeeper/apac
he‐zookeeper‐3.5.8‐bin/data‐dir/version‐2/snapshot.0

快照事务日志文件名为： snapshot.<当时最大事务ID>，日志满了即进行下一次事务日志文件的
创建。

有了事务日志，为啥还要快照数据？

快照数据主要时为了快速恢复，事务日志文件是每次事务请求都会进行追加的操作，而快照是达
到某种设定条件下的内存全量数据。所以通常快照数据是反应当时内存数据的状态。事务日志是
更全面的数据，所以恢复数据的时候，可以先恢复快照数据，再通过增量恢复事务日志中的数据
即可。

7.Zookeeper 集群

Zookeeper 集群模式一共有三种类型的角色：

Leader: 处理所有的事务请求（写请求），可以处理读请求，集群中只能有一个Leader
Follower：只能处理读请求，同时作为 Leader的候选节点，即如果Leader宕机，Follower节点
要参与到新的Leader选举中，有可能成为新的Leader节点。
Observer：只能处理读请求。不能参与选举。

8. ZAB协议介绍

整个Zookeeper就是一个多节点分布式一致性算法的实现，底层采用的实现协议是ZAB。
ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。
Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议，ZAB是Paxos算法的一种简化实现。
ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复和原子广播的协议。

基于该协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：

上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到Leader节点，然后，由 Leader 复制到Follower节点中，从而保证数据一致性。

那么复制过程又是如何的呢？

复制过程类似两阶段提交(2PC)，ZAB 只需要 Follower(含leader自己的ack) 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

开始重点介绍消息广播和崩溃恢复。整个 Zookeeper 就是在这两个模式之间切换。简而言之，当 Leader 服务可以正常使用，就进入消息广播模式，当 Leader 不可用时，则进入崩溃恢复模式。

8.1消息广播

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个两阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数(含leader自己)成功响应，则执行 commit 操作。
整个广播流程如下：

通过以上步骤，就能够保持集群之间数据的一致性。

还有一些细节：

1. Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理，主要通过消息队列实现。
2. 在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。
3. zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的写请求，也会转发到 Leader 服务器进行处理，Follower只能处理读请求。
4. ZAB协议规定了如果一个事务在一台机器上被处理(commit)成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。

8.2崩溃恢复

消息广播过程中，Leader 崩溃怎么办？还能保证数据一致吗？
实际上，当 Leader 崩溃，即进入崩溃恢复模式（崩溃即：Leader 失去与过半 Follwer 的联系）。

下面来详细讲述。
假设1：Leader 在复制数据给所有 Follwer 之后，还没来得及收到Follower的ack返回就崩溃，怎么办？
假设2：Leader 在收到 ack 并提交了自己，同时发送了部分 commit 出去之后崩溃怎么办？

针对这些问题，ZAB 定义了 2 个原则：

1. ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
2. ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。

所以，ZAB 设计了下面这样一个选举算法：
能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。
针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器 ZXID 最大的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

数据同步
当崩溃恢复之后，需要在正式工作之前（接收客户端请求），Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了，即是否完成了数据同步。目的是为了保持数据一致。
当 Follwer 服务器成功同步之后，Leader 会将这些服务器加入到可用服务器列表中。

实际上，Leader 服务器处理或丢弃事务都是依赖着 ZXID 的，那么这个 ZXID 如何生成呢？

答：在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。
而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值(leader选举周期)，当一轮新的选举结束后，会对这个值加一，并且事务id又从0开始自增。