简单的入个zookeeper门

简单的入个zookeeper门

1. 什么是Zookeeper

没接触zk之前，总觉得他很牛逼；感觉在哪都能看到它的身影；所以才下定决心在秋招到来之前把它从头到尾掌握一遍；理解他的核心设计原理，甚至会深入源码；有兴趣的可以留意一下后面的博文；

那么不多cc，直接来了解一下什么是zk；有哪些使用场景

• 协调框架：zk最多的应用场景估计就是在分布式场景的应用了；那么什么是分布式系统呢？一个分布式系统的本质是分布在不同网络或计算机上的程序组件，彼此通过 信息传递来协同工作的系统，而Zookeeper正是一个分布式应用协调框架，在分布式系统架构中 有广泛的应用场景。
• 作用：用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同 步服务、集群管理、分布式应用配置项的管理等。

这些解释还是有点抽象：毕竟还有实际应用过，不是很理解；总之可以理解为它就是一个和redis差不多的基于内存的数据库；存储形式为文件系统形式；

2. Zookeeper核心概念

文件系统数据结构

如何理解这个文件系统数据结构？我们可以打开windows文件系统；

大文件夹里面有小文件；

文件夹又包含一些信息：

好了到这你已经了解百分之80的zk的设计了；它就是基于文件系统形式来存储数据的；只不过他的文件夹（也就是目录，以下都称为目录）有许多种形式；下面就来意义介绍它们

• PERSISTENT­持久化目录节点

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

• PERSISTENT_SEQUENTIAL­持久化顺序编号目录节点

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

• EPHEMERAL­临时目录节点

客户端与zookeeper断开连接后，该节点被删除

• EPHEMERAL_SEQUENTIAL­临时顺序编号目录节点

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

• Container 节点（3.5.3 版本新增，如果Container节点下面没有子节点，则Container节点

在未来会被Zookeeper自动清除,定时任务默认60s 检查一次）

• TTL 节点( 默认禁用，只能通过系统配置 zookeeper.extendedTypesEnabled=true 开启，不稳

定)

看文字会疲劳，看图

一下就清晰很多了是吧；具体有什么使用场景在后续的实战使用会介绍的；

监听通知机制

如果说文件系统是zk的地基的话，那么监听通知就是地基上面的一栋高楼；有了它才能是的zk华丽无比；

• 监听：也就是多某个目录进行监听；监听的意义就是希望目标发生改变我能知道；那要如何才能知道呢；
• 通知：被监听的目录在被改变之后会主动发送通知给监听者；

1. 如果注册的是对某个节点的监听，则当这个节点被删除，或者被修改时，对应的客户端将被通

知

2. 如果注册的是对某个目录的监听，则当这个目录有子节点被创建，或者有子节点被删除，对应

的客户端将被通知

3. 如果注册的是对某个目录的递归子节点进行监听，则当这个目录下面的任意子节点有目录结构

的变化（有子节点被创建，或被删除）或者根节点有数据变化时，对应的客户端将被通知。

注意！：所有的监听通知都是一对一的而且是一次性的；一次监听用过之后就删除了；

使用场景

1. 分布式配置中心

2. 分布式注册中心

3. 分布式锁

4. 分布式队列

5. 集群选举

6. 分布式屏障

7. 发布/订阅

3. Zookeeper实操

要使用当然首先下载了！直接去官网下载：

zk使用java写的，当然需要准备java的环境

我推荐使用linux操作zk；安装java也很简单，用命令就能实现，不用配置环境；不会的伙伴可以搜一下；

当然zk得下载也可以使用命令wget

wget https://dlcdn.apache.org/zookeeper/zookeeper-3.8.0/apache-zookeeper-3.8.0-bin.tar.gz

相信解压之类的就不用介绍了；

解压之后可以看到文件分布：

很简单就几个文件：启动的话肯定到bin目录启动脚本；不过在启动之前我们通常会拷贝一份配置文件；随意玩弄

cp zoo_sample.cfg zoo.cfg

启动
bin/zkServer.sh start conf/zoo.cfg
启动客户端连接
bin/zkCli.sh -server localhost:2181

使用客户端命令操作

具体操作各位自行尝试；此处列出个命令作用：

键入help:

使用参考–命令操作大全

4. Zookeeper ACLs权限控制

redis详细大家都有了解；redis的数据不具安全性，谁都能访问，没有权限控制（6.0后加入）

但是zk就具备了权限控制功能；就像文件系统一样；每个目录都有相应的读写权限；zk也差不多就是这样

数据节点（c: create）创建权限，授予权限的对象可以在数据节点下创建子节点；

数据节点（w: wirte）更新权限，授予权限的对象可以更新该数据节点；

数据节点（r: read）读取权限，授予权限的对象可以读取该节点的内容以及子节点的列表信息；

数据节点（d: delete）删除权限，授予权限的对象可以删除该数据节点的子节点；

数据节点（a: admin）管理者权限，授予权限的对象可以对该数据节点体进行 ACL 权限设置。

• 命令：

setAcl 设置某个节点的acl权限信息
getAcl 获取某个节点的acl权限信息
addAuth  注册用户，注册时输入明文做密码，zk使用加密保存

首先看setAcl，有两种方式

create /zk‐node datatest digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa //创建时设置
setAcl /zk‐node digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa //直接设置

后面一串乱码是什么？

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 种：

所以后面的乱码就是生成后的授权ID；如何生成呢？

echo ‐n <user>:<password> | openssl dgst ‐binary ‐sha1 | openssl base64

这样拿到id就可对某个节点设置权限了；

访问结点需要注册用户 addauth digest gj:test

另外可以直接使用明文设置权限

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

IP授权：

1 setAcl /node‐ip ip:192.168.109.128:cdwra 
2 create /node‐ip data ip:192.168.109.128:cdwra

5. ZooKeeper 内存数据和持久化

既然是基于内存的小型数据库，肯定要面临数据持久化问题，像redis一样，又ＲＤＢ、AOF两种那么zk也不会差多少，也是运用了这两种持久化思想来实现的

既然zk是java写的，那我们可以看一手zk源码，看它是如何设计数据存放的，以什么样的形式：

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

由此可见，它是利用concurrentHashmap来存储的，一个字符串对应一个DataNode

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

zk的持久化有两种方式：事务日志、原始快照，详细熟悉redis的朋友看名字就知道如何实现的了

• 事务日志：客户端的每一次操作，zk都会把他们记录到事务日志当中；该日志文件会保存到配置文件中dataLogs中；通过一些工具将日志文件转化为比较易懂的格式如下：

这样zk在挂机重连后就可重新执行这些事务便可恢复数据；

• 原始快照：全量复制数据；在某一时刻全量赋值服务器上的数据并写入指定的磁盘文件中；

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

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