Zookeeper 知识摘要

Zookeeper 知识摘要

两大核心概念

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

zookeeper单机的话能抗上万的并发

文件系统数据结构

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 开启，不稳定

监听通知机制

客户端注册监听它关心的任意节点，或者目录节点及递归子目录节点

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

经典应用场景

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

实战

1. 创建子节点命令

create [‐s] [‐e] [‐c] [‐t ttl] path [data] [acl]

s是有序节点，e是临时节点，c是容器节点，t ttl 是可以给节点添加过期时间，默认禁用，需要通过.sh添加系统JVM参数启用。不带参数默认持久化节点
有序节点就是创建会带有顺序
临时节点就是跟一次客户端的sessionId长连接绑定，客户端断开连接后，临时节点不会马上被服务端清除，默认有个30s的样子，如果30秒内重新连接服务端了之后sessionId也会变，还是能看到临时节点，过了时间照样会被清除，但是服务端会有个保活机制，后续了解，

注意：临时节点下面不能有子节点

容器节点就是也是个非临时节点，只是如果容器节点下面的子节点都被删除完之后，等到默认60s一次的定时任务cpu轮询到了当前容器节点就会被清除，用于实现分布式锁。

create /pre 123   创建一个持久化节点
create -s /pre  111 创建一个有序持久化节点
create -e /pre  123  创建一个临时节点
create -s -e /pre  123 创建一个临时有序节点
create -c /pre  123  创建一个容器节点

2.查看节点命令

 ls [-s] [-w] [-R] path

s是节点状态 w是监听 -R递归查看当前目录下所有节点

使用ls -w -R /pre 123 的话
会递归监听子目录，而不是只监听一次，但是也是一次失效，其他目录还有
但是不会监听节点数据，所以节点数据改变监听不到

 get [-s] [-w] path

s是可以查看节点状态，w是添加一个监听事件，监听事件只监听一次
节点的状态有
cZxid：创建znode的事务ID（Zxid的值）。
mZxid：最后修改znode的事务ID。
pZxid：最后添加或删除子节点的事务ID（子节点列表发生变化才会发生改变）。
ctime：znode创建时间。
mtime：znode最近修改时间。
dataVersion：znode的当前数据版本。
cversion：znode的子节点结果集版本（一个节点的子节点增加、删除都会影响这个
版本）。
aclVersion：表示对此znode的acl版本。
ephemeralOwner：znode是临时znode时，表示znode所有者的 session ID。 如果
znode不是临时znode，则该字段设置为零。
dataLength：znode数据字段的长度。numChildren：znode的子znode的数量。

3.修改节点命令

根据状态数据中的版本号有并发修改数据实现乐观锁的功能

set [-s] [-v version] path data

s都是查看节点状态 v是版本

set -v 1 /pre 123  可以修改成功
set -v 1 /pre 123   在用以前的版本修改就失败

4. 删除节点命令

 delete [-v version] path
 deleteall path [-b batch size]

Zookeeper监听事件类型

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

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 [-s] path  查看结点权限信息
 setAcl [-s] [-v version] [-R] path acl  设置结点权限信息
 addauth scheme auth 输入认证授权信息，相当于注册用户信息，注册时输入明文密码，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 中生成

echo ‐n <user>:<password> | openssl dgst ‐binary ‐sha1 | openssl base64
echo ‐n gi:test | openssl dgst ‐binary ‐sha1 | openssl base64
就会生成X/NSthOB0fD/OT6iilJ55WJVado= 在创建是添加权限是用

设置ACL有两种方式
节点创建的同时设置AC

create [-s] [-e] [-c] path [data] [acl]
create /zk‐node datatest digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa
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   gi是用户名  test是密码
get /zk‐node
datatest

另一种授权模式： auth 明文授权

使用之前需要先
addauth digest username:password 注册用户信息，后续可以直接用明文授权

addauth digist user1:pass1
create /pre 1234 auth:user1:pass1:cdwra  要加数据否侧会把授权信息当作数据保存
这是user1用户授权信息会被zk保存，可以认为当前的授权用户为user1
get /pre
1234

IP授权模式：

setAcl /pre ip:172.168.109.221:cdwra
create /pre 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))

zk内存数据和持久化

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;

事务日志

针对每一次客户端的事务操作，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，日志满了即进行下一次事务日志文件的创建

数据快照

数据快照用于记录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

D:\zookeeper\apache-zookeeper-3.6.2-bin\data\version-2
在目录下面snapshot的是数据快照，log的是事务日志

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

创建有了事务日志，为啥还要快照数据。

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

zookeeper客户端Curator

封装了zookeeper的java客户端
可以递归创建结点，zookeeper原始客户端不能递归创建结点
分布式锁的实现
leader选举 基于公平锁实现的
注册中心
多个服务生成一个服务UUid通过create临时结点的方式保存当前服务的ip-port-weight信息，临时结点的话，当前服务挂掉了话，通过一定的心跳机制后判断已经挂掉，结点信息就可以被删除了，其他服务要依赖哪个服务的话直接通过路径可以拿取所有子节点也就是服务多实例的信息，拿的同时添加监听，服务信息更改后可以感知到然后重新获取并监听，然后可以保存到本地，本地实现一个负载均衡算法去实现服务调用，
拉取保存在本地这种是springCloud Ribbon 实现的一种方式，没用zookeeper用的什么临时节点啊啥的，他有自己的心跳检测机制，所以服务down机了也不会马上剔除，

调用方可以不把自己注册到zookeeper上去，可以去调用别人，而不想别人调用你的话可以在yml文件中设置为false

 spring.application.name=user‐center #就是zookeeper下结点路径，多个实例就多个，默认在zookeeper下先创建个service结点，再就是服务名的结点
 #zookeeper 连接地址 ，
 #如果使用了 spring cloud zookeeper config这个配置应该配置在bootstrap.yml/bootstrap.properties中
 spring.cloud.zookeeper.connect‐string=192.168.109.200:2181
#将本服务注册到zookeeper，如果不希望自己被发现可以配置为false, 默认为 true
 spring.cloud.zookeeper.discovery.register=true

分布式锁的时候 创建临时有序结点 -0 -1 -2 等每个节点监听前面一个，每次判断自己是否是最小的，不是就监听前面一个，
他有一个是创建锁路径方法createsTheLock（），再一个就是获取锁的方法internalLockLoop（）里面的getsTheLock（）方法
创建结点的时候 可能因为网络原因，请求创建成功了，但是服务端响应失败，会请求在创建一次，这样就会有两个结点创建，前面的结点没有指向无法释放，就是所说的幽灵结点，这个问题curator有一个保护模式，规避幽灵结点，在你创建临时顺序结点的时候他会在你前面附加一个UUid，唯一标识，所以客户端重试创建的时候他会去找你这个UUid存不存在，存在的话他就不会重复创建了 在Curator里面的一个callWithRetry方法实现的

//获得curator客户端
CuratorFramework curatorFramework = getCuratorFramework(); 

//获取数据 同步的 可以进行异步
curatorFramework.getData().forPath("/curator-node");  
//获得公平锁 也就是分布式锁
InterProcessMutex interProcessMutex=new InterProcessMutex(curatorFramework,"/mode+id");
        interProcessMutex.acquire();
//防止 读写不一致 双写不一致  用读写锁 共享锁实现

zookeeper集群搭建

首先配置4个一样的zoo.cfg 配置里面端口号2181，21821，2183，2184等data日志保存路径，这个路径下面要添加一个myid文件，里面就是服务id1，2，3，4，这样，然后配置服务端口如下，

dataDir=/usr/local/data/zookeeper‐1
 clientPort=2181
 server.1=127.0.0.1:2001:3001:participant// participant 可以不用写，默认就是part
icipant
 server.2=127.0.0.1:2002:3002:participant
 server.3=127.0.0.1:2003:3003:participant
 server.4=127.0.0.1:2004:3004:observer

启动3台服务
bin/zkServer.sh start conf/zoo1.cfg
bin/zkServer.sh start conf/zoo2.cfg
bin/zkServer.sh start conf/zoo3.cfg
查看leader follwer状态
bin/zkServer.sh status conf/zoo1.cfg
bin/zkServer.sh status conf/zoo2.cfg
bin/zkServer.sh status conf/zoo3.cfg
客户端启动，需要加多个服务ip和端口，这样连接上的服务挂了还会进行重连
 bin/zkCli.sh ‐server ip1:port1,ip2:port2,ip3:port3

配置说明

tickTime：用于配置Zookeeper中最小时间单位的长度，很多运行时的时间间隔都是
使用tickTime的倍数来表示的。
initLimit：该参数用于配置Leader服务器等待Follower启动，并完成数据同步的时
间。Follower服务器再启动过程中，会与Leader建立连接并完成数据的同步，从而确定自
己对外提供服务的起始状态。Leader服务器允许Follower再initLimit 时间内完成这个工
作。
syncLimit：Leader 与Follower心跳检测的最大延时时间
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将
写数据的日志文件也保存在这个目录里。
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监
听这个端口，接受客户端的访问请求。
server.A=B：C：D：E 其中 A 是一个数字，表示这个是第几号服务器；B 是这个服
务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D
表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新
的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配
置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给
它们分配不同的端口号。如果需要通过添加不参与集群选举以及事务请求的过半机制的
Observer节点，可以在E的位置，添加observer标识。