zookeeper

介绍

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

Zookeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储数据的状态变化。通过监控这些数据状态的变化，从而达到基于数据的集群管理、统一全名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
Zookeeper从设计模型角度来理解：是一个基于观察者模型设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经注册到Zookeeper上的那些观察者做出反应。

安装

官网地址：https://zookeeper.apache.org/

• 下载页面

• 选择版本
  

#windows，点击链接下载

#centos8
mkdir /usr/local/soft
cd /usr/local/soft
#下载
wget https://dlcdn.apache.org/zookeeper/zookeeper-3.8.4/apache-zookeeper-3.8.4-bin.tar.gz

#解压
tar -vxf apache-zookeeper-3.8.4-bin.tar.gz
ls

zookeeper 结构

• 查看结构

cd /usr/local/soft/apache-zookeeper-3.8.4-bin/
tree bin conf logs

• 配置文件

bin/zkServer.sh
cd conf
cp zoo_sample.cfg  zoo.cfg
cd ..

# 可以通过 bin/zkServer.sh  来查看都支持哪些参数 
# 默认加载配置路径conf/zoo.cfg
bin/zkServer.sh start
bin/zkServer.sh start conf/my_zoo.cfg

# 查看zookeeper状态
bin/zkServer.sh status

• 配置文件

# The number of milliseconds of each tick
# zookeeper时间配置中的基本单位（毫秒）
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
# 允许follower初始化连接到leeader最大时长，它表示tickTime时间的倍数
# 即initlLimit*tickTime
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
#允许follower与leadr数据同步最大时长，它表示tickTime时间的倍数
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
# zookeeper 数据存储目录及日志保存目录（如果没有指明dataLogDir，则日志也保存在这个文件中）
dataDir=/tmp/zookeeper
# the port at which the clients will connect
#对客户端提供的端口号
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
# 单个客户端与zooKeeper最大并发连接数
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
# 数据快照数量，之外的将会被清除
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
# 自动触发清除任务时间间隔，小时为单位。默认为0，表示不自动清除
#autopurge.purgeInterval=1

## Metrics Providers
#
# https://prometheus.io Metrics Exporter
#metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
#metricsProvider.httpHost=0.0.0.0
#metricsProvider.httpPort=7000
#metricsProvider.exportJvmInfo=true

• 启动zookeeper客户端连接zookeeper server

bin/zkCli.sh
#连接远程的zookeeper server
bin/zkCli.sh -server ip:port

客户端命令行操作

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

#查看命令
help

常见cli命令

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

命令基本语法	功能描述
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节点(有时间限制的节点)，-t时间(单位毫秒) data:节点的数据，可选，如果不使用时，节点的数据就为null acl:访问控制
get [-s][-w]	获取节点的数据信息 -s:节点状态信息（时间戳、版本号、数据大小等） -w:监听节点变化
set [-s][-v version] path data	设置节点 -s:表示节点为顺序节点 -v:指定版本号
getAcl [-s] path	获取节点的访问控制信息 -s:节点状态信息（时间戳、版本号、数据大小等）
setAcl [-s][-v version][-R] path acl	设置节点的访问控制列表 -s:节点状态信息（时间戳、版本号、数据大小等） -v:指定版本号 -R:递归的设置
stat [-w] path	查看节点的状态信息
delete [-v version] path	删除某一节点，只能删除无子节点的节点 -v:表示节点版本呈号
deleteall path	递归删除某一节点及其子节点
setquota -n|-b val path	对节点增加限制 n:表示子节点的最大个数 b:数据值的最大长度，-1表示无限制

#根目录下的节点
ls / 
ls -R /
ls -s /
ls -w /

• 创建节点

#创建节点
create /test01
#设置节点值
set /test01 xxx
#查看节点值
get /test01
#创建二级节点
create /test01/user
#删除节点
delete /test01/user

Zookeeper数据结构

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

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 ConcurrentHasMap<string,DataNode>();

    private final WatchManager dataWatches = new WatchManager();
    private final WatchManager childWatches = new WatchManager();
}

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

节点分类

zookeeper 存在几种不同的节点类型，他们具有不同的生命周期：

类型	生命周期	创建示例
持久节点(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是持久性或临时性节点：
1.持久节点(PERSISTENT):ZNode被创建后，即使发生Zookeeper集群宕机或client宕机也不会丢失。
2.临时节点(EPHEMERAL):client宕机或client在指定timeout时间内没有给Zookeeper集群发消息，ZNode就会消失。

如果上面两种ZNode具备顺序性，又有以下两种ZNode：
3.持久顺序节点(PERSISTENT_SEQUENTIAL):ZNode除了具备持久性特点外，名字具备顺序性。
4.临时顺序节点(EPHEMERAL_SEQUENTIAL):Znode除了具备临时性特点外，名字具备顺序性。
Zookeeper主要到以上4种节点。

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

6.TTL节点:含有过时间节点，默认禁用，需要在zoo.cfg中添加 extentedTypesEnabled=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

示例：实现分布式锁
分布式锁要求，如果锁持有者宕了，锁可以被释放。Zookeeper的ephemerial节点恰好具备这样特性。
终端1：

zkCli.sh
create -e /lock
quit

终端2：

zkcli.sh
create -e /lock
stat -w /lock
create -e /lock

节点状态
类似树状结构，节点可以存储一些信息与属性，通过state命令查看

• 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: 子节点的数量（只统计直接子节点的数量）

示例：zookeeper乐观锁删除

监听机制详解

watch机制，顾名思义是一个监听机制。Zookeeper的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知客户端。
监听对象是事件，支持事件类型如下：

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

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

特性	说明
一次性触发	watch 是一次性触发，一旦触发就会被移除，再次使用时需要重新注册
客户端顺序回调	watch回调是顺序串行执行，只有回调后客户端才能看到最新数据状态。一个watch回调逻辑不应该太多，以免影响其他watch执行
轻量级	WatchEvent是最少的通信单位，结构上只包含通知状态、事件类型和节点路径，并不会告诉数据节点变化前后的具体内容
时效性	watcher只有在当前session彻底失效时才会无效，若在session有效期内快速重连成功，则watcher依然会存在，仍可接收到通知。

永久性Watch
在被触发后，仍然保留，继续监听ZNode上的变更，是Zookeepe3.6.0版本新增的功能

addWatch [-m mode] path

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

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

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

# master1
create -e /master "m1:2223"

# master2 
create -e /master "m2:2223" # /master 已经存在 ，创建失败
Node already exists: /mast
# 监听 /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服务会收到子节点变化通知

# master 服务
ls -w /workers
# worker2 
create -e /workers/w2 "w2:2224" # 创建子节点,master服务会怀到子节点变化通知

# master 服务
ls -w /workers
# worker2
quit # worker2退出，master服务会收到子节点变化通知

示例：条件更新
设想用ZNode /c 实现一个counter,使用set命令实现自增1操作。条件更新场景：
1.客户端1 把 /c 更新到版本1,实现 /c 的自增1.
2.客户端2 把 /c 更新到版本2,实现 /c 的自增1.
3.客户端1不知道 /c 已以被客户端2 更新过了，还用过时的版本1去更新 /c, 更新失败。如果客户端1使用的是无条件更新， /c 会更新为2，没有实现自增1.
使用条件更新可避免出现客户端基于过期的数据进行数据更新的操作。

节点特性总结

1.同一级节点key铝箔是唯一

已存在/lock节点，再次创建会提示已经存在
2.创建节点时，必须带上全路径
3.session关闭，临时节点清除
4.自动创建顺序节点

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

应用场景详解

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

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

统一会命名服务

在分布式环境下，经常需要对应用/服务进行统一全名，便于识别。
例如：IP不容易记住，而域名容易记住。

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

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

数据发布/订阅

数据发布订阅的一个常见场景是配置中心，发布者把数据发布到Zookeeper的一个或一系列的节点上，供订阅进行数据订阅，达到动态获取数据的目的。
配置信息一般有如下几个特点
1.数据量小的KV(Key-Value)
2.数据内容在运行时会发生动态变化
3.集群机器共享，配置一般

Zookeeper 采用推拉结合的方式
1.推：服务端会推给注册了监控节点的客户端Watcher事件通知
2.拉：客户端获得通知后，主动到服务器端拉取最新的数据

统一集群管理

分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。
Zookeeper可以实现实时监控节点状态变化：

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

负载均衡

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

Master-Worker结构

master-worker是一个广泛使用的分布式架构。master-worker架构中有一个master负责监控worker的状态，并为worker分配任务。

• 在任何时刻，系统中最多只能有一个master,不可以出现两个master的情况，多个master共存会导致脑裂。
• 系统中除了处于active状态的master还有一个backup master，如果active master状态失败了，backup master 可以很快的进入active状态。
• master 实时监控worker的状态，能够及时收到worker成员变化的通知。master收到worker成员变化的时候，通常进行任务的重新分配。
  

ACL权限控制

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

ACL构成

Zookeeper的acl 通过 [scheme🆔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)。
  |模式 | 描述|
  |--- |---|
  |world | 授权对象只有一个anyone，代表登录到服务器的所有客户端都能对该节点执行某种权限 |
  |ip| 对连接的客户端使用IP地址认证的方式进行认证 |
  |auth | 使用已添加认证的用户进行认证 |
  |digest | 使用用户：密码方式验证|

权限类型	ACL简写	描述
read	r	读取节点及显示子节点列表的权限
write	w	设置节点数据的权限
create	c	创建子节点的权限
delete	d	删除子节点的权限
admin	a	设置节点ACL权限的权限

授权命令	用法	描述
getAcl	getAct path	读取节点的ACL
setAcl	setAcl path acl	设置节点的ACL
create	create path data acl	创建节点时设置ACL
addAuth	addAuth scheme auth	添加认证用户，类似登录操作

测试

取消节点的读权限后，读取 /name 节点没有权限

取消节点删除子节点的权限

auth 授权模式

创建用户

addauth digest fox:123456

设置权限

setAcl /name auth:fox:123456:cdrwa

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

退出客户端，重新连接之后获取 /name 会没权限，需要添加授权用户

digest 授权模式

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

IP授权模式

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

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

Super超级管理员模式

这是一种特殊的Digest模式，在Super模式下超级管理员用户可以对Zookeeper上的节点进行任何操作。
需要在启动脚本上通过添加JVM参数开启：

#DigestAuthenticationProvider 中定义
-Dzookeeper.DigestAuthenticationProvider.supperDigest=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();

}

Zookeeper集群架构

集群角色

• Leader: 领导者
  事务请求（写操作）的唯一调度者和处理者，保证集群事务处理的顺序性。集群内部各个服务的调度者。对于create、setData、delete等有写操作的请求，则要统一转发给Leader处理，Leader需要决定编号、执行操作，这个过程称为事务。
• Follower 跟随者
  处理客户端非事务（读操作）请求（可以直接响应），转发事务请求给Leader，参与集群Leader选举投票。
• Observer 观察者
  对于非事务请求可以独立处理（读操作），对于事务性请求会转发给Leader处理。Observer节点接收来自Leader的inform信息，更新自己本地存储，不参与提交和选举投票，通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

#配置一个ID为3的观察者节点
server.3=192.168.0.3:2888:3888:observer

Observer应用场景：

• 提升集群的可读性。因为Observer不参与提交和选举的投票过程，所以可以通过往集群中添加observer节点来提高整个集群的读性能。
• 跨数据中心部署。比如需要部署一个北京和香港两地都可以使用的zookeeper集群服务，并且要求北说和香港客户户的读请求延迟都很低。解决方案就是把香港的节点都设置为observer。

集群架构

Leader节点可以处理读写请求，follower只可以读请求。follower在接到写请求时会把写请求转发给leader来处理。

Zookeeper数据一致性保证：

• 全局可线性化（Linearizable）写入：先到达leader的写请求会被先处理，leader决定写请求的执行顺序。
• 客户端FIFO顺序：来自给定客户端的请求按照发送顺序执行。

三节点Zookeeper集群搭建

环境准备：三台虚拟机

192.168.65.163
192.168.65.184
192.168.65.186

也可以在一台虚拟机上搭建伪集群

1>修改zoo.cfg配置，添加server节点配置

#修改数据存储目录 
dataDir=/data/zookeeper

#三台虚拟机 zoo.cfg 文件末尾添加配置
server.1=192.168.65.163:2888:3888
server.1=192.168.65.184:2888:3888
server.1=192.168.65.186:2888:3888

server.A=B:C:D
A 是一个数字，表示这个是第几号服务器，集群模式下配置一个文件myid,这个文件在dataDir目录下，这个文件里面有一个数据就是A的值，Zookeeper启动时读取此文件，拿到里面的数据与zoo.cfg里面的配置信息比较从而判断到底是哪个server。
B 是这个服务器的地址
C 是这个服务器Floower与集群中的Leader服务器交换信息的端口
D 是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新Leader，而这个端口就是用来执行选举时服务器相互通信的端口

2> 创建myid文件，配置服务器编号
在dataDir对应的目录下创建myid文件，内容为对应的ip的Zookeeper服务器编号

cd /data/zookeeper
#在文件中添加与server对应的编号（注意：上下不要有空行，左右不要有空格）
vim myid

注意：添加myid文件时，一定要在 linux里面创建，在notepad++里面很可能乱码

3>启动zookeeper servera集群
启动前需要关闭防火墙（生产环境需要打开对应端口）

#分别启动三个节点的zookeeper  server
bin/zkSserver.sh start
#查看集群状态
bin/zkServer.sh status

常见问题：
如果服务启动出现下面异常：

原因：
1.zoo.cfg配置错误
2.防火墙没关

#centos7
# 检查防火墙状态
systemctl  status firewalld
#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

Zookeeper 四字命令使用

用户可以使用Zookeeper四字命令获取Zookeeper服务的当前状态及相关信息。用户在客户端可以通过nc(netcat)向zookeeper提交相应命令。
安装nc:

#centos
yum install nc

四字命令

echo [command] |nc [ip] [port]

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版本引入。输出可用于检测集群健康状态的变量列表。

https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_4lw

开启四字命令
方法1： 在zoo.cfg文件中加入配置项

#开启四字命令
4lw.commands.whitelist=*

方法2：在zk启动脚本zkServer.sh中增加命令

#添加JVM环境变量-Dzookeeper.4lw.commands.whitelist=*
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"

stat 命令
stat 命令用于查看zk的状态信息，实例如下：

echo stat |nc 192.168.65.186 2181

ruok命令
用于查看当前zkserver是否启动，若返回imok表示正常

echo ruok | nc 192.168.65.186 2181

Zookeeper选举原理

Zookeeper的Lead选举过程是基于投票和对比规则，确保集群中选出一个具有最高优先级的服务器作为Leader来处理客户端请求。以服务启动期间选举为例：

投票对比规则如下：

• 首先比较epoch,选取具有最大epoch的服务器。epoch用于区分不同的选举轮次，每次重新选举时都会增加epoch。
• 如果epoch相同，则比较zxid(事物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){
    LOG.debug(
      "id: {}, proposed id:{}, zxid: 0x{},proposed zxid: 0x{}",
      newId,
      curId,
      Long.toHexString(newZxid),
      Long.toHexString(curZxid));
    
    if (self.getQuorumVerifler().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 > curEpochJ)
            || ((newEpoch == curEpoch)
                && ((newZxid > curZxid)
                     || ((newZxid == curZxid)
                           &&(newId > curId)))));

}

zxid的数据结构
根据这个工具类，可以得出zxid的数据结构的一些信息。
1.zxid是一个64位的整数，由高32位的epoch和低32位的counter组成。
2.epoch表示Zookeeper服务器的逻辑时期(logical epoch), 它是一个相对时间的概念，用于区分不同的Leader选举周期。
3.counter是一个在每个时期(epoch)内递增的计数器，用于标识事务的顺序 。

public class ZxidUtils {

    public static 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);
    }
       
}