桥下の民 - Zookeeper
type: channel
link: https://wordplay.work/index.php/category/Zookeeper
items: Zookeeper ACL
items: Zookeeper 日志&快照
items: Dubbo配置&高可用&原理
items: Dubbo 简介
items: Zookeeper 脑裂问题
items: Zookeeper

Zookeeper ACL
type: item
date: 2024-06-06T01:48:00+00:00
description: 一、ACL 介绍 ZooKeeper 作为一个分布式协调框架，内部存储的都是一些分布式系统运行时状态的元数据，尤其是一些涉及到分布式锁，master 选举和分布式协调等应用场景的数据，数据的访问权限涉及到 ZooKeeper 运行时安全。为了保障 ZooKeeper 的数据安全，提供了一套完整的 ACL (Access Control List) 权限控制机制来保障数据的安全。 ACL 的实现和 UNIX 的实现非常相似：它采用权限位来控制哪些操作被允许，哪些操作被禁止。但是和标准的 UNIX 权限不同的是，Znode 没有限制用户（user，即文件的所有者），组（group）和其他（world）。Zookeepr 是没有所有者的概念的。 每个 ZNode 的 ACL 是独立的，且子节点不会继承父节点的 ACL。例如：Znode/app 对于 ip 为 172.16.16.1 只有只读权限，而 /app/status 是 world 可读，那么任何人都可以获取 /app/status。所以在 Zookeeper 中权限是没有继承和传递关系的，每个 Znode 的权限都是独立存在的。 Zookeeper 支持可插拔的权限认证方案，分为三个维度：scheme，user，permission。通常表示为 [scheme:id:permissions]，其中 Scheme 表示使用何种方式来进行访问控制（使用何种权限验证机制），id 代表用户，Permission 表示有什么权限（权限组合字符串）。 一个 ZooKeeper 的节点 (znode) 存储两部分内容：数据和状态，状态中包含 ACL 信息。创建一个 znode 会产生一个 ACL 列表，列表中每个 ACL 包括以上三个维度。 二、ACL 的构成 2.1、scheme（权限模式） scheme 有以下几种类型： world：world 下只有一个 id，即只有一个用户，也就是 anyone，那么组合的写法就是 world:anyone:[permissions]。 ip：当设置为 ip 指定的 ip 地址，此时限制 ip 进行访问，比如 ip:192.168.77.130:[permissions]。也可以通过配置 IP 网段的方式，例如 “ip:192.168.28.1/24:[permissions]”，表示针对 192.168.28.* 整个 IP 段进行权限控制。 auth：代表认证登录，需要注册用户获取权限后才可以登录访问，形式为 auth:userpassword:[permissions]。 digest：需要对密码加密才能访问，组合形式为：digest:username:BASE64 (SHA1 (password)):[permissions]。具体的实现是由 DigestAuthenticationProvider.generateDigest () 方法来保证的。 super：代表超级管理员，拥有所有的权限，可以操作 ZooKeeper 上的任意节点数据。 auth 与 digest 的区别就是，前者使用明文密码进行登录，后者使用密文密码进行登录。 setAcl /path auth:lee:lee:cdrwa 与 setAcl /path digest:lee:BASE64 (SHA1 (password)):cdrwa 是等价的，在通过 addauth digest lee:lee 后都能操作指定节点的权限。在实际情况中，digest 要更为常用一些。 注意的是， exists 操作和 getAcl 操作并不受 ACL 许可控制，因此任何客户端可以查询节点的状态和节点的 ACL 。 2.2、id（授权对象） 对于不同的 scheme，授权的对象是不同的： IP 模式：授权对象通常是一个 ip 地址或者是一个 ip 段； Digest 模式：授权对象通常是自定义中的 username； World 模式：授权对象是 anyone； Super 模式：授权对象和 Digest 中的相同； 2.3、permissions（权限） 权限字符串缩写 crdwa ： CREATE：创建子节点权限（允许对子节点 Create 操作）； READ：访问节点 / 子节点权限（允许对本节点 GetChildren 和 GetData 操作）； WRITE：设置节点数据权限（允许对本节点 SetData 操作）； DELETE：删除子节点权限（允许对子节点 Delete 操作）； ADMIN：管理员权限（允许对本节点 setAcl 操作）； 三、ACL 命令 3.1、ACL 命令行操作 getAcl：获取某个节点的 ACL 权限信息； setAcl：设置某个节点的 AC…

Zookeeper 日志&快照
type: item
date: 2024-03-07T07:01:00+00:00
description: 一、Zookeeper 日志 Zookeeper 服务器会产生三类日志：事务日志、快照日志和 log4j 日志。 在 zookeeper 默认配置文件 zoo.cfg（可以修改文件名）中有一个配置项 dataDir，该配置项用于配置 zookeeper 快照日志和事务日志的存储地址。在官方提供的默认参考配置文件 zoo_sample.cfg 中，只有 dataDir 配置项。其实在实际应用中，还可以为事务日志专门配置存储地址，配置项名称为 dataLogDir，在 zoo_sample.cfg 中并未体现出来。 在没有 dataLogDir 配置项的时候，zookeeper 默认将事务日志文件和快照日志文件都存储在 dataDir 对应的目录下。建议将事务日志（dataLogDir）与快照日志（dataLog）单独配置，因为当 zookeeper 集群进行频繁的数据读写操作是，会产生大量的事务日志信息，将两类日志分开存储会提高系统性能，而且，可以允许将两类日志存在在不同的存储介质上，减少磁盘压力。 log4j 用于记录 zookeeper 集群服务器运行日志，该日志的配置地址在 conf/ 目录下的 log4j.properties 文件中，该文件中有一个配置项为 zookeeper.log.dir=.，表示 log4j 日志文件在与执行程序（zkServer.sh）在同一目录下。当执行 zkServer.sh 时，在该文件夹下会产生 zookeeper.out 日志文件。 二、事务日志 事务日志指 zookeeper 系统在正常运行过程中，针对所有的更新操作，在返回客户端 “更新成功” 的响应前，zookeeper 会保证已经将本次更新操作的事务日志已经写到磁盘上，只有这样，整个更新操作才会生效。 根据上文所述，可以通过 zoo.cfg 文件中的 dataLogDir 配置项找到事物日志存储地点： 在 datalog/ 目录下存在一个文件夹 version-2，该文件夹中保存着事物日志文件: 日志文件的命名规则为 log.，文件大小为 64MB 表示写入该日志的第一个事务的 ID，十六进制表示。 三、事务日志可视化 Zookeeper 的事务日志为二进制文件，不能通过 vim 等工具直接访问。其实可以通过 zookeeper 自带的 jar 包读取事务日志文件。 首先将 libs 中的 slf4j-api-1.6.1.jar 文件和 zookeeper 根目录下的 zookeeper-3.4.9.jar 文件复制到临时文件夹 tmplibs 中，然后执行如下命令： java -classpath .:slf4j-api-1.7.25.jar:zookeeper-3.4.14.jar org.apache.zookeeper.server.LogFormatter/opt/zookeeper/transactionLog/version-2/log.504e25800 > a.txt 其中：/opt/zookeeper/transactionLog/version-2/log.4 是日志路径下的日志文件。 命令是在 zookeeper 的 bin 目录下执行的，因此使用.:lib。 zookeeper-3.4.14.jar 表示我所使用的 zk 版本是 3.4.12 版本。 四、快照日志 Zookeeper 的数据在内存中是以树形结构进行存储的，而快照就是每隔一段时间就会把整个 DataTree 的数据序列化后存储在磁盘中，这就是 zookeeper 的快照文件。 zookeeper 快照日志的存储路径同样可以在 zoo.cfg 中查看，如上文截图所示。访问 dataDir 路径可以看到 version-2 文件夹: 从截图中可以看出，zookeeper 快照文件的命名规则为 snapshot.**，其中 ** 表示 zookeeper 触发快照的那个瞬间，提交的最后一个事务的 ID。 五、日志清理 在 zookeeper 3.4.0 以后，zookeeper 提供了自动清理 snapshot 和事务日志功能，通过配置 zoo.cfg 下的。 autopurge.snapRetainCount 和 autopurge.purgeInterval 这两个参数实现日志文件的定时清理： autopurge.snapRetainCount 这个参数指定了需要保留的文件数目，默认保留 3 个。 autopurge.purgeInterval 这个参数指定了清理频率，单位是小时，需要填写一个 1 或者更大的数据，默认 0 表示不开启自动清理功能。 六、事务日志和快照日志的关联 ZooKeeper 集群中的每个服务器节点每次接收到写操作请求…

Dubbo配置&高可用&原理
type: item
date: 2022-07-24T07:40:00+00:00
description: 一、dubbo配置 1.1、配置原则 JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。 XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。 Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。 1.2、重试次数 失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。 重试次数配置如下： <dubbo:service retries="2" /> 或 <dubbo:reference retries="2" /> 或 <dubbo:reference> <dubbo:method name="findFoo" retries="2" /> </dubbo:reference> 1.3、超时时间 由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。 1、Dubbo消费端 全局超时配置 <dubbo:consumer timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:reference interface="com.foo.BarService" timeout="2000"> <dubbo:method name="sayHello" timeout="3000" /> </dubbo:reference> 2、Dubbo服务端 全局超时配置 <dubbo:provider timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:provider interface="com.foo.BarService" timeout="2000"> <dubbo:method name="sayHello" timeout="3000" /> </dubbo:provider> 3、配置原则 dubbo 推荐在 Provider 上尽量多配置 Consumer 端属性： 1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等。 2、在 Provider 配置后，Consumer 不配置则会使用 Provider 的配置值，即 Provider 配置可以作为 Consumer 的缺省值。否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的。 配置的覆盖规则： 方法级配置别优于接口级别，即小 Scope 优先 。 Consumer 端配置 优于 Provider 配置 优于全局配置。 最后是 Dubbo Hard Code 的配置值（见配置文档）。 1.4、版本号 当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。 可以按照以下的步骤进行版本迁移： 在低压力时间段，先升级一半提供者为新版本。 再将所有消费者升级为新版本。 然后将剩下的一半提供者升级为新版本。 老版本服务提供者配置： <dubbo:service interface="com.foo.BarService" version="1.0.0" /> 新版本服务提供者配置： <dubbo:service interface="com.foo.BarService" version="2.0.0" /> 老版本服务消费者配置： <dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> 新版本服务消费者配置： <dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" /> 如果不需要区分版本，可以按照以下的方式配置： <dubbo:reference id="barService" interface="com.foo.BarService" version="*" /> 二、高可用 2.1、zookeeper宕机与dubbo直连 现象：zookeeper 注册中心宕机，还可以消费 dubbo 暴露的服务。 原因： 健壮性： 监控中心宕掉不影响使用，只是丢失部分采样数据。 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务。 注册中心对等集群，任意一台宕掉后，将自动切换到另一台。 注册中心全部宕掉后，服务提供者和服务消费者仍能通过…

Dubbo 简介
type: item
date: 2022-07-24T07:36:00+00:00
description: 一、dubbo核心概念 1.1、简介 Apache Dubbo (incubating) 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 官网：http://dubbo.apache.org/ 1.2、基本概念 服务提供者(Provider)：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者(Consumer): 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 注册中心(Registry)：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 监控中心(Monitor)：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 调用关系说明： 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 二、dubbo环境搭建 2.1、【windows】-安装zookeeper 1、下载zookeeper 网址：https://archive.apache.org/dist/zookeeper/zookeeper-3.4.13/ 2、解压zookeeper 解压运行zkServer.cmd，初次运行会报错，没有zoo.cfg配置文件。 3、修改zoo.cfg配置文件 将 conf 下的 zoo_sample.cfg 复制一份改名为 zoo.cfg 即可。 注意几个重要位置： dataDir=./ 临时数据存储的目录（可写相对路径） clientPort=2181 zookeeper的端口号 修改完成后再次启动 zookeeper。 4、使用zkCli.cmd测试 ls /：列出zookeeper根下保存的所有节点 create –e /atguigu 123：创建一个atguigu节点，值为123 get /test：获取/test节点的值 2.2、【windows】-安装dubbo-admin管理控制台 dubbo 本身并不是一个服务软件。它其实就是一个 jar 包能够帮你的 java 程序连接到zookeeper，并利用 zookeeper 消费、提供服务。所以不用在 Linux 上启动什么 dubbo 服务。 但是为了让用户更好的管理监控众多的 dubbo 服务，官方提供了一个可视化的监控程序，不过这个监控即使不装也不影响使用。 1、下载dubbo-admin https://github.com/apache/incubator-dubbo-ops 2、进入目录，修改dubbo-admin配置 修改 src\main\resources\application.properties 指定zookeeper地址 3、打包dubbo-admin mvn clean package -Dmaven.test.skip=true 4、运行dubbo-admin java -jar dubbo-admin-0.0.1-SNAPSHOT.jar 注意：【有可能控制台看着启动了，但是网页打不开，需要在控制台按下ctrl+c即可】 默认使用 root/root 登录。 2.3、【linux】-安装zookeeper 1、安装jdk 1、下载jdk http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html 2、上传到服务器并解压 3、设置环境变量 vim /etc/profile 文件末尾加入下面配置 export JAVA_HOME=/usr/local/java/jdk1.8.0_171 export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH 4、使环境变量生效&测试JDK 2、安装zookeeper 1、下载zookeeper 网址：h…

Zookeeper 脑裂问题
type: item
date: 2022-04-02T04:52:00+00:00
description: 一、简介 ZooKeeper 是用来协调 (同步) 分布式进程的服务，提供了一个简单高性能的协调内核，用户可以在此之上构建更多复杂的分布式协调功能。脑裂通常会出现在集群环境中，比如 ElasticSearch、Zookeeper 集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如 ElasticSearch 集群中有 Master 节点，Zookeeper 集群中有 Leader 节点。 二、奇数节点 zookeeper 容错指的是：当宕掉几个 zookeeper 节点服务器之后，剩下的个数必须大于宕掉的个数，也就是剩下的节点服务数必须大于 n/2，这样 zookeeper 集群才可以继续使用，无论奇偶数都可以选举 leader。例如 5 台 zookeeper 节点机器最多宕掉 2 台，还可以继续使用，因为剩下 3 台大于 5/2。那么为什么最好为奇数个节点呢？是在以最大容错服务器个数的条件下，会节省资源。比如，最大容错为 2 的情况下，对应的 zookeeper 服务数，奇数为 5，而偶数为 6，也就是 6 个 zookeeper 服务的情况下最多能宕掉 2 个服务，所以从节约资源的角度看，没必要部署 6 (偶数) 个 zookeeper 服务节点。 zookeeper 集群有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有 2 个 zookeeper 节点，那么只要有 1 个 zookeeper 节点死了，那么 zookeeper 服务就不能用了，因为 1 没有过半，所以 2 个 zookeeper 的死亡容忍度为 0；同理，要是有 3 个 zookeeper，一个死了，还剩下 2 个正常的，过半了，所以 3 个 zookeeper 的容忍度为 1；同理也可以多列举几个：2->0; 3->1; 4->1; 5->2; 6->2 就会发现一个规律，2n 和 2n-1 的容忍度是一样的，都是 n-1，所以为了更加高效，何必增加那一个不必要的 zookeeper 呢。 根据以上可以得出结论：从资源节省的角度来考虑，zookeeper 集群的节点最好要部署成奇数个。 三、集群脑裂场景说明 对于一个集群，想要提高这个集群的可用性，通常会采用多机房部署，比如现有一个由 6 台 zkServer 所组成的一个集群，部署在了两个机房： 正常情况下，此集群只会有一个 Leader，那么如果机房之间的网络断了之后，两个机房内的 zkServer 还是可以相互通信的，如果不考虑过半机制，那么就会出现每个机房内部都将选出一个 Leader。 这就相当于原本一个集群，被分成了两个集群，出现了两个 "大脑"，这就是所谓的 脑裂现象。对于这种情况，其实也可以看出来，原本应该是统一的一个集群对外提供服务的，现在变成了两个集群同时对外提供服务，如果过了一会，断了的网络突然联通了，那么此时就会出现问题了，两个集群刚刚都对外提供服务了，数据该怎么合并，数据冲突怎么解决等等问题。刚刚在说明脑裂场景时有一个前提条件就是没有考虑过半机制，所以实际上 Zookeeper 集群中是不会轻易出现脑裂问题的，原因在于过半机制。 zookeeper 的过半机制：在领导者选举的过程中，如果某台 zkServer 获得了超过半数的选票，则此 zkServer 就可以成为 Leader 了。 举个简单的例子：如果现在集群中有 5 台 zkServer，那么 half=5/2=2，那么也就是说，领导者选举的过程中至少要有三台 zkServer 投了同一个 zkServer，才会符合过半机制，才能选出来一个 Leader。 问题 1：zookeeper 选举的过程中为什么一定要有一个过半机制验证？因为这样不需要等待所有 zkServer 都投了同一个 zkServer 就可以选举出来一个 Leader 了，这样比较快，所以叫快速领导者选举算法。 问题 2：过半机制中为什么是大于，而不是大于等于呢？这就是更脑裂问题有关系了，比如回到上文出现脑裂问题的场景。 当机房中间的网络断掉之后，机房 1 内的三台服务器会进行领导者选举，但是此时过半机制的条件是 "节点数 > 3"，也就是说至少要 4 台 zkServer 才能选出来一个 Leader，所以对于机房 1 来说它不能选出一个 Leader，同样机房 2 也不能选出一个 Leader，这种情况下整个集群当机房间的网络断掉后，整个集群将没有 Leader。 而如果过半机制的条件是 "节点数 >= 3"，那么机房 1 和机房 2 都会选出一个 Leader，这样就出现了脑裂。这就可以解释为什么过半机制中是大于而不是大于等于，目的就是为了防止脑裂。 假设我们现在只有 5 台机器，也部署在…

Zookeeper
type: item
date: 2022-04-01T05:12:00+00:00
description: 一、Zookeeper 入门 1.1、概述 Zookeeper 是一个开源的分布式的，为分布式框架提供协调服务的 Apache 项目。 Zookeeper 工作机制 Zookeeper 从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应。 1.2、特点 1、Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。 2、集群中只要有半数以上节点存活，Zookeeper 集群就能正常服务。所以 Zookeeper 适合安装奇数台服务器。 3、全局数据一致：每个 Server 保存一份相同的数据副本，Client 无论连接到哪个 Server，数据都是一致的。 4、更新请求顺序执行，来自同一个 Client 的更新请求按其发送顺序依次执行。 5、数据更新原子性，一次数据更新要么成功，要么失败。 6、实时性，在一定时间范围内，Client 能读到最新数据。 1.3、数据结构 ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。 1.4、应用场景 提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。 1.4.1、统一命名服务 在分布式环境下，经常需要对应用 / 服务进行统一命名，便于识别。 例如：IP 不容易记住，而域名容易记住。 1.4.2、统一配置管理 1）分布式环境下，配置文件同步非常常见。 （1）一般要求一个集群中，所有节点的配置信息是 一致的，比如 Kafka 集群。 （2）对配置文件修改后，希望能够快速同步到各个节点上。 2）配置管理可交由 ZooKeeper 实现。 （1）可将配置信息写入 ZooKeeper 上的一个 Znode。 （2）各个客户端服务器监听这个 Znode。 （3）一旦 Znode 中的数据被修改，ZooKeeper 将通知 各个客户端服务器。 1.4.3、统一集群管理 1）分布式环境中，实时掌握每个节点的状态是必要的。 （1）可根据节点实时状态做出一些调整。 2）ZooKeeper 可以实现实时监控节点状态变化 （1）可将节点信息写入 ZooKeeper 上的一个 ZNode。 （2）监听这个 ZNode 可获取它的实时状态变化。 1.4.4、服务器动态上下线 1.4.5、软负载均衡 在 Zookeeper 中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求 1.5、下载地址 1）官网首页： https://zookeeper.apache.org/ 2）下载截图 3）下载 Linux 环境安装的 tar 包 二、Zookeeper 本地安装 2.1、本地模式安装 1）安装前准备 （1）安装 JDK （2）拷贝 apache-zookeeper-3.5.7-bin.tar.gz 安装包到 Linux 系统下 （3）解压到指定目录 tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /opt/module/ （4）修改名称 mv apache-zookeeper-3.5.7-bin/zookeeper-3.5.7 2）配置修改 （1）将 /opt/module/zookeeper-3.5.7/conf 这个路径下的 zoo_sample.cfg 修改为 zoo.cfg； mv zoo_sample.cfg zoo.cfg （2）打开 zoo.cfg 文件，修改 dataDir 路径： vim zoo.cfg 修改如下内容： dataDir=/opt/module/zookeeper-3.5.7/zkData （3）在 /opt/module/zookeeper-3.5.7/ 这个目录上创建 zkData 文件夹 mkdir zkData 3）操作 Zookeeper （1）启动 Zookeeper [atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkServer.sh start （2）查看进程是否启动 [atguigu@hadoop102 zookeeper-3.5.7]$ jps 4020 Jps 4001 QuorumPeerMain （3）查看状态 atguigu@hadoop102 zookeeper-3.5.7]$ ./bin/zkServer.sh staus ZooKeep…