1. Zookeeper介绍
ZooKeeper 是一个开源的分布式协调框架，是 Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
（图：Zookeeper 架构示意图 — Actor（用户）通过 Zookeeper 协调多个 Service 节点）
ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper = 文件系统 + 监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
（图：Zookeeper 集群架构图 — Client1/2/3 与 Server1/2/3 通过注册中心交互；1.服务启动时注册信息（创建临时节点）；2.获取当前在线server列表，并且监听；3.服务节点下线；4.server节点下线通知；5.重新获取server列表，并注册监听）
2. Zookeeper快速开始
2.1 Zookeeper安装
下载地址： zookeeper.apache.org/releases.ht…
运行环境：jdk8
1）修改配置文件
解压安装包后进入 conf 目录，复制 zoo_sample.cfg，修改为 zoo.cfg
修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的 data 目录
cp zoo_sample.cfg zoo.cfg
zoo.cfg 中参数含义：
2）启动 zookeeper server
# 可以通过 bin/zkServer.sh 来查看都支持哪些参数
# 默认加载配置路径 conf/zoo.cfg
3）启动 zookeeper client 连接 Zookeeper server
bin/zkServer.sh start
bin/zkServer.sh start conf/my_zoo.cfg
# 查看 zookeeper 状态
bin/zkServer.sh status
# 连接本地 zk server
bin/zkCli.sh
# 连接远程的 zookeeper server
bin/zkCli.sh -server ip:port
输入命令 help 查看所有命令。
2.2 客户端命令行操作
常见 cli 命令：zookeeper.apache.org/doc/r3.8.0/…
| 命令基本语法 | 功能描述 | |
|---|---|---|
help | 显示所有操作命令 | |
ls [-s] [-w] [-R] path | 使用 ls 命令来查看当前 znode 的子节点 [可监听] -w: 监听子节点变化 -s: 节点状态信息（时间戳、版本号、数据大小等） -R: 表示递归的获取 | |
create [-s] [-e] [-c] [-t ttl] path [data] [acl] | 创建节点 -s : 创建有序节点 -e : 创建临时节点 -c : 创建容器节点 -t ttl : 创建一个 TTL 节点（时间单位毫秒） data：节点的数据，可选 acl：访问控制 | |
get [-s] [-w] path | 获取节点数据信息 | |
set [-s] [-v version] path data | 设置节点数据 -s: 表示节点为顺序节点 -v: 指定版本号 | |
getAcl [-s] path | 获取节点的访问控制信息 | |
setAcl [-s] [-v version] [-R] path acl | 设置节点的访问控制列表 | |
stat [-w] path | 查看节点状态信息 | |
delete [-v version] path | 删除某一节点，只能删除无子节点的节点 | |
deleteall path | 递归的删除某一节点及其子节点 | |
| `setquota -n | -b val path` | 对节点增加限制 n: 子节点的最大个数 b: 数据值的最大长度，-1表示无限制 |
2.3 GUI 工具
Zookeeper 图形化工具：
- ZooInspector — 开源
- prettyZoo — 开源
- ZooKeeperAssistant — 收费
3. ZooKeeper 数据结构
文件系统的树形结构便于表达数据之间的层次关系，也便于为不同的应用分配独立的命名空间（namespace）。
ZooKeeper 的层次模型称作 Data Tree，Data Tree 的每个节点叫作 Znode。不同于文件系统，每个节点都可以保存数据，每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从 0 开始计数。
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();
}
public class DataNode implements Record {
byte data[];
Long acl;
public StatPersisted stat;
private Set<String> children = null;
}
3.1 节点分类
| 类型 | 生命周期 | 创建示例 |
|---|---|---|
| 持久节点 (persistent node) | 一直存在，一直存储在 ZooKeeper 服务器上，即使创建该节点的客户端与服务端的会话关闭了，该节点依然不会被删除 | create /locks |
| 临时节点 (ephemeral node) | 当创建该临时节点的客户端会话因超时或发生异常而关闭时，该节点也相应在 ZooKeeper 服务器上被删除 | create -e /locks/DBLock |
| 有序节点 (sequential node) | 并不算是一种单独种类的节点，而是在持久节点和临时节点特性的基础上增加了一个节点有序的性质。创建有序节点时会自动使用一个单调递增的数字作为后缀 | create -e -s /jobs/job （有序临时节点） |
| 容器节点 (container node) | 当一个容器节点的最后一个子节点被删除后，容器节点也会被删除 | create -c /work |
| TTL节点 (ttl node) | 当一个 TTL 节点在 TTL 内没有被修改并且没有子节点，会被删除。注意：默认此功能不开启，需要修改配置文件 extendedTypesEnabled=true | create -t 3000 /ttl_node |
一个 znode 可以是持久性的，也可以是临时性的：
- 持久节点 (PERSISTENT)： 这样的 znode 在创建之后即使发生 ZooKeeper 集群宕机或者 client 宕机也不会丢失。
- 临时节点 (EPHEMERAL)： client 宕机或者 client 在指定的 timeout 时间内没有给 ZooKeeper 集群发消息，这样的 znode 就会消失。
- 持久顺序节点 (PERSISTENT_SEQUENTIAL)： znode 除了具备持久性 znode 的特点之外，znode 的名字具备顺序性。
- 临时顺序节点 (EPHEMERAL_SEQUENTIAL)： znode 除了具备临时性 znode 的特点之外，znode 的名字具备顺序性。
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
节点状态信息
类似于树状结构，节点下面是可以存储一些信息和属性的。可以通过 stat 命令来进行查看。
对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeper Transaction Id），通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1 小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。
| 属性 | 含义 |
|---|---|
| cZxid | Znode 创建的事务 id |
| ctime | 节点创建时的时间戳 |
| mZxid | Znode 被修改的事务 id，即每次对 znode 的修改都会更新 mZxid |
| pZxid | 表示该节点的子节点列表最后一次修改的事务 ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID（注意：只有子节点列表变更了才会变更 pz xid，子节点内容变更不会影响 pz xid） |
| mtime | 节点最新一次更新发生时的时间戳 |
| cversion | 子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1 |
| dataVersion | 数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题 |
| ephemeralOwner | 如果该节点为临时节点，ephemeralOwner 值表示与该节点绑定的 session id。如果不是，ephemeralOwner 值为 0（持久节点） |
| dataLength | 数据的长度 |
| numChildren | 子节点的数量（只统计直接子节点的数量） |
示例：实现分布式锁
分布式锁要求如果锁的持有者宕了，锁可以被释放。ZooKeeper 的 ephemeral 节点恰好具备这样的特性。
终端1：
zkCli.sh
create –e /lock
quit
终端2：
zkCli.sh
create –e /lock # Node already exists
stat –w /lock # 监听
create –e /lock # 终端1退出后可成功创建
示例：zookeeper 乐观锁删除
条件更新场景：
- 客户端1把 /c 更新到版本1，实现 /c 的自增1
- 客户端2把 /c 更新到版本2，实现 /c 的自增1
- 客户端1不知道 /c 已经被客户端2更新过了，还用过时的版本1去更新 /c，更新失败。如果客户端1使用的是无条件更新，/c 就会更新为2，没有实现自增1
使用条件更新可以避免出现客户端基于过期的数据进行数据更新的操作。
3.2 监听机制详解
在 client 和 server 通信之前，首先需要建立连接，该连接称为 session。连接建立后，如果发生连接超时、授权失败，或者显式关闭连接，连接便处于 closed 状态，此时 session 结束。
watch 机制，顾名思义是一个监听机制。Zookeeper 中的 watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。
监听的对象是事件，支持的事件类型如下：
| 事件类型 | 说明 |
|---|---|
| None | 连接建立事件 |
| NodeCreated | 节点创建 |
| NodeDeleted | 节点删除 |
| NodeDataChanged | 节点数据变化 |
| NodeChildrenChanged | 子节点列表变化 |
| DataWatchRemoved | 节点监听被移除 |
| ChildWatchRemoved | 子节点监听被移除 |
watch 特性：
| 特性 | 说明 |
|---|---|
| 一次性触发 | watch 是一次性的，一旦被触发就会移除，再次使用时需要重新注册 |
| 客户端顺序回调 | watch 回调是顺序串行执行的，只有回调后客户端才能看到最新的数据状态。一个 watcher 回调逻辑不应该太多，以免影响别的 watch 执行 |
| 轻量级 | WatchEvent 是最小的通信单位，结构上只包含通知状态、事件类型和节点路径，并不会告诉数据节点变化前后的具体内容 |
| 时效性 | watcher 只有在当前 session 彻底失效时才会无效，若在 session 有效期内快速重连成功，则 watcher 依然存在，仍可接收到通知 |
永久性 Watch（ZK 3.6.0 新增）： addWatch 在被触发之后仍然保留，可以继续监听 ZNode 上的变更。
addWatch 作用是针对指定节点添加事件监听，支持两种模式：
addWatch [-m mode] path
- PERSISTENT：持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
- PERSISTENT_RECURSIVE：持久化递归订阅（默认），在 PERSISTENT 的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
# 监听节点数据的变化
get -w path
stat -w path
# 监听子节点增减的变化
ls -w path
示例：协同服务（Master-Worker 组成员管理）
设计一个 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 选举也可以用这种方式。
master 监控 worker 状态的设计思路
# master 服务
create /workers
# 让 master 服务监控 /workers 下的子节点
ls -w /workers
# worker1
create -e /workers/w1 "w1:2224" # 创建子节点，master服务会收到子节点变化通知
# worker2
create -e /workers/w2 "w2:2224" # 创建子节点，master服务会收到子节点变化通知
# worker2
quit # worker2 退出，master服务会收到子节点变化通知
3.3 节点特性总结
- 同一级节点 key 名称是唯一的（已存在 /lock 节点，再次创建会提示已经存在）
- 创建节点时，必须要带上全路径
- session 关闭，临时节点清除
- 自动创建顺序节点
- watch 机制，监听节点变化
- delete 命令只能一层一层删除（提示：新版本可以通过
deleteall命令递归删除）
事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。 ZooKeeper 适用于存储和协同相关的关键数据，不适合用于大数据量存储。
3.4 应用场景详解
有了上述众多节点特性，使得 zookeeper 能开发出不同的经典应用场景，比如：
| 应用场景 | 说明 |
|---|---|
| 注册中心 | 服务注册与发现 |
| 数据发布/订阅 | 常用于实现配置中心 |
| 负载均衡 | 根据访问数动态分配请求 |
| 命名服务 | 统一命名管理 |
| 分布式协调/通知 | 分布式系统间协调通信 |
| 集群管理 | 实时监控节点状态变化 |
| Master 选举 | 确保同一时刻只有唯一的 Master |
| 分布式锁 | 基于临时+有序节点实现互斥 |
| 分布式队列 | 基于 Zookeeper 实现先进先出队列 |
| 分布式序列号生成器 | 利用顺序节点特性生成全局唯一 ID |
统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。例如：IP 不容易记住，而域名容易记住。
利用 Zookeeper 顺序节点的特性，制作分布式的序列号生成器，或者叫 id 生成器。（分布式环境下使用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。
/
└── /order
├── /order-date1-000000000000001
├── /order-date2-000000000000002
├── /order-date3-000000000000003
├── /order-date4-000000000000004
└── /order-date5-000000000000005
数据发布/订阅（配置中心）
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。
配置信息一般有几个特点：
- 数据量小的 KV
- 数据内容在运行时会发生动态变化
- 集群机器共享，配置一致
ZooKeeper 采用的是推拉结合的方式：
- 推： 服务端会推给注册了监控节点的客户端 Watcher 事件通知
- 拉： 客户端获得通知后，然后主动到服务端拉取最新的数据
统一集群管理
分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。ZooKeeper 可以实现实时监控节点状态变化。
负载均衡
在 Zookeeper 中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。
Master-Worker 架构
Master-Work 是一个广泛使用的分布式架构。master-work 架构中有一个 master 负责监控 worker 的状态，并为 worker 分分任务。
- 在任何时刻，系统中最多只能有一个 master，不可以出现两个 master 的情况，多个 master 共存会导致脑裂。
- 系统中除了处于 active 状态的 master 还有一个 backup master，如果 active master 失败了，backup master 可以很快的进入 active 状态。
- master 实时监控 worker 的状态，能够及时收到 worker 成员变化的通知。master 在收到 worker 成员变化的时候，通常重新进行任务的重新分配。
- 可将节点信息写入 ZooKeeper 上的一个 ZNode。监听这个 ZNode 可获取它的实时状态变化。
3.5 ACL 权限控制
Zookeeper 的 ACL（Access Control List，访问控制表）权限在生产环境是特别重要的，ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。
zookeeper 的 acl 通过 [scheme:id:permissions] 来构成权限列表。
ACL 构成
| 组成部分 | 描述 |
|---|---|
| scheme | 授权的模式，代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种 |
| id | 授权对象，代表允许访问的用户。如果选择采用 IP 方式，授权对象可以是 IP 地址或 IP 地址段；如果使用 Digest 或 Super 方式，对应于一个用户名；如果是 World 模式，是授权系统中所有的用户 |
| permissions | 授权的权限，权限组合字符串，由 cdrwa 组成 |
权限类型
| ACL简写 | 描述 |
|---|---|
| read (r) | 读取节点及显示子节点列表的权限 |
| write (w) | 设置节点数据的权限 |
| create (c) | 创建子节点的权限 |
| delete (d) | 删除子节点的权限 |
| admin (a) | 设置该节点 ACL 权限的权限 |
授权模式
| 模式 | 描述 |
|---|---|
| world | 授权对象只有一个 anyone，代表登录到服务器的所有客户端都能对该节点执行某种权限 |
| ip | 对连接的客户端使用 IP 地址认证方式进行认证 |
| auth | 使用以添加认证的用户进行认证 |
| digest | 使用 用户:密码 方式验证 |
授权命令
| 命令 | 用法 | 描述 |
|---|---|---|
| getAcl | getAcl path | 读取节点的 ACL |
| setAcl | setAcl path acl | 设置节点的 ACL |
| create | create path data acl | 创建节点时设置 acl |
| addAuth | addAuth scheme auth | 添加认证用户，类似于登录操作 |
auth 授权模式
# 添加认证用户
addauth digest gengtle:123456
# 设置权限
setAcl /name auth:gengtle:123456:cdrwa
# 加密密码
echo -n fox:123456 | openssl dgst -binary -sha1 | openssl base64
setAcl /name auth:gengtle:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa
digest 授权模式
# 设置权限
setAcl /zoo/gengtle digest:gengtle:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa
测试流程：
- 取消节点的读权限后，读取 /name 节点没有权限
- 取消节点删除子节点的权限
- 退出客户端，重新连接之后获取 /name 会没权限，需要添加授权用户
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 参数开启：
# DigestAuthenticationProvider 中定义
-Dzookeeper.DigestAuthenticationProvider.superDigest=admin:<base64encoded(SHA1(123456))>
可插拔身份验证接口
ZooKeeper 提供了一种权限扩展机制来让用户实现自己的权限控制方式。要想实现自定义的权限控制机制，需要继承接口 AuthenticationProvider：
public interface AuthenticationProvider {
// 返回标识插件的字符串
String getScheme();
// 将用户和验证信息关联起来
KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]);
// 验证 id 格式
boolean isValid(String id);
// 将认证信息与 ACL 进行匹配看是否命中
boolean matches(String id, String aclExpr);
// 是否授权
boolean isAuthenticated();
}
4. Zookeeper 集群架构
4.1 集群角色
| 角色 | 描述 |
|---|---|
| Leader | 领导者。事务请求（写操作）的唯一调度者和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于 create、setData、delete 等有写操作的请求，则要统一转发给 leader 处理，leader 需要决定编号、执行操作，这个过程称为事务 |
| Follower | 跟随者。处理客户端非事务（读操作）请求（可以直接响应），转发事务请求给 Leader；参与集群 Leader 选举投票。对于非事务请求可以独立处理（读操作），对于事务性请求会转发给 leader 处理 |
| Observer | 观察者。接收来自 leader 的 inform 信息，更新自己的本地存储，不参与提交和选举投票。通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力 |
leader 节点可以处理读写请求，follower 只可以处理读请求。follower 在接到写请求时会把写请求转发给 leader 来处理。
Zookeeper 数据一致性保证：
- 全局可线性化 (Linearizable) 写入： 先到达 leader 的写请求会被先处理，leader 决定写请求的执行顺序
- 客户端 FIFO 顺序： 来自给定客户端的请求按照发送顺序执行
Observer 应用场景
- 提升集群的读性能： 因为 Observer 不参与提交和选举的投票过程，所以可以通过往集群里面添加 observer 节点来提高整个集群的读性能
- 跨数据中心部署： 比如需要部署一个北京和香港两地都可以使用的 zookeeper 集群服务，并且要求北京和香港客户的读请求延迟都很低。解决方案就是把香港的节点都设置为 observer
# 配置一个 ID 为 3 的观察者节点：
server.3=192.168.0.3:2888:3888:observer
4.2 集群架构
（图：Zookeeper 集群架构 — Leader/Follower/Observer 角色关系与数据同步流程）
4.3 三节点 Zookeeper 集群搭建
环境准备：三台虚拟机（条件有限也可以在一台虚拟机上搭建 zookeeper 伪集群）
192.168.65.163
192.168.65.184
192.168.65.186
1）修改 zoo.cfg 配置，添加 server 节点配置
格式：server.A=B:C:D
- A 是一个数字，表示这个是第几号服务器；集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个 server
- B 是这个服务器的地址
- C 是这个服务器 Follower 与集群中的 Leader 服务器交换信息的端口
- D 是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口
# 修改数据存储目录
dataDir=/data/zookeeper
# 三台虚拟机 zoo.cfg 文件末尾添加配置
server.1=192.168.65.163:2888:3888
server.2=192.168.65.184:2888:3888
server.3=192.168.65.186:2888:3888
2）创建 myid 文件，配置服务器编号
在 dataDir 对应目录下创建 myid 文件，内容为对应 ip 的 zookeeper 服务器编号
注意： 添加 myid 文件，一定要在 Linux 里面创建，在 notepad++ 里面很可能乱码
cd /data/zookeeper
# 在文件中添加与 server 对应的编号（注意：上下不要有空行，左右不要有空格）
vim myid
3）启动 zookeeper server 集群
启动前需要关闭防火墙（生产环境需要打开对应端口）
# 分别启动三个节点的 zookeeper server
bin/zkServer.sh start
# 查看集群状态
bin/zkServer.sh status
常见问题： 如果服务启动出现异常，原因可能是：
- zoo.cfg 配置错误
- 防火墙没关
# centos7
systemctl status firewalld # 检查防火墙状态
systemctl stop firewalld # 关闭防火墙
systemctl disable firewalld # 禁止开机启动
4.4 Zookeeper 四字命令使用
用户可以使用 Zookeeper 四字命令获取 zookeeper 服务的当前状态及相关信息。用户在客户端可以通过 nc（netcat）向 zookeeper 提交相应的命令。
四字命令格式：echo [command] | nc [ip] [port]
安装 nc 命令：
# centos
yum install nc
开启四字命令
方法1： 在 zoo.cfg 文件里加入配置项让这些指令放行
方法2： 在 zk 的启动脚本 zkServer.sh 中新增放行指令
# 开启四字命令（方法1：zoo.cfg 中添加）
4lw.commands.whitelist=*
# 方法2：zkServer.sh 启动脚本中添加 JVM 环境变量
-Dzookeeper.4lw.commands.whitelist=*
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"
ZooKeeper 常用四字命令
| 四字命令 | 功能描述 |
|---|---|
| conf | 3.3.0 版本引入。打印出服务相关配置的详细信息 |
| cons | 3.3.0 版本引入。列出所有连接到这台服务器的客户端全部连接/会话详细信息。包括"接受/发送"的包数量、会话 id、操作延迟、最后的操作执行等等信息 |
| crst | 3.3.0 版本引入。重置所有连接的连接和会话统计信息 |
| dump | 列出那些比较重要的会话和临时节点。这个命令只能在 leader 节点上有用 |
| envi | 打印出服务环境的详细信息 |
| reqs | 列出未经处理的请求 |
| ruok | 测试服务是否处于正确状态。如果确实如此，那么服务返回"imok"，否则不做任何响应 |
| stat | 输出关于性能和连接的客户端的列表 |
| srst | 重置服务器的统计 |
| srvr | 3.3.0 版本引入。列出连接服务器的详细信息 |
| wchs | 3.3.0 版本引入。列出服务器 watch 的详细信息 |
| wchc | 3.3.0 版本引入。通过 session 列出服务器 watch 的详细信息，输出是一个与 watch 相关的话话的列表 |
| wchp | 3.3.0 版本引入。通过路径列出服务器 watch 的详细信息。输出一个与 session 相关的路径 |
| mntr | 3.4.0 版本引入。输出可用于检测集群健康状态的变量列表 |
参考文档：zookeeper.apache.org/doc/current…
# 使用示例
echo stat | nc 192.168.65.186 2181
echo ruok | nc 192.168.65.186 2181
4.5 Zookeeper 选举原理
ZooKeeper 的 Leader 选举过程是基于投票和对比规则的，确保集群中选出一个具有最高优先级的服务器作为 Leader 来处理客户端请求。以服务启动期间选举为例：
投票对比规则如下：
- 首先比较 epoch，选取具有最大 epoch 的服务器。epoch 用于区分不同的选举轮次，每次重新选举时都会增加 epoch
- 如果 epoch 相同，则比较 zxid（事务 ID），选取事务 ID 最大的服务器。zxid 表示最后一次提交的事务 ID
- 如果 zxid 也相同，则比较 myid（服务器 ID），选取服务器 ID 最大的服务器
/**
* Check if a pair (server id, zxid) succeeds our current vote.
*/
protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch,
long curId, long curZxid, long curEpoch) {
if (self.getQuorumVerifier().getWeight(newId) == 0) {
return false;
}
/*
* We return true if one of the following three cases hold:
* 1- New epoch is higher
* 2- New epoch is the same as current epoch, but new zxid is higher
* 3- New epoch is the same as current epoch, new zxid is the same
* as current zxid, but server id is higher.
*/
return ((newEpoch > curEpoch)
|| ((newEpoch == curEpoch)
&& ((newZxid > curZxid)
|| ((newZxid == curZxid)
&& (newId > curId)))));
}
zxid 的数据结构
zxid 是一个 64 位的整数，由高 32 位的 epoch 和低 32 位的 counter 组成。
- epoch：表示 ZooKeeper 服务器的逻辑时期（logical epoch），它是一个相对时间的概念，用于区分不同的 Leader 选举周期
- counter：是一个在每个时期（epoch）内递增的计数器，用于标识事务的顺序
public class ZxidUtils {
public static long getEpochFromZxid(long zxid) {
return zxid >> 32L;
}
public static long getCounterFromZxid(long zxid) {
return zxid & 0xffffffffL;
}
public static long makeZxid(long epoch, long counter) {
return (epoch << 32L) | (counter & 0xffffffffL);
}
public static String zxidToString(long zxid) {
return Long.toHexString(zxid);
}
}
