Apache > ZooKeeper
 
 

ZooKeeper 管理员指南

部署和管理指南

部署

本节包含有关部署 ZooKeeper 的信息，涵盖以下主题

前两节假设您有兴趣在生产环境（例如数据中心）中安装 ZooKeeper。最后一节涵盖了您在有限范围内设置 ZooKeeper 的情况 - 用于评估、测试或开发 - 但不是在生产环境中。

系统要求

支持的平台

ZooKeeper 由多个组件组成。某些组件得到广泛支持，而其他组件仅在较小的平台集上受支持。

以下矩阵描述了在不同操作系统平台上运行每个组件的支持级别。

支持矩阵
操作系统客户端服务器原生客户端Contrib
GNU/Linux开发和生产开发和生产开发和生产开发和生产
Solaris开发和生产开发和生产不支持不支持
FreeBSD开发和生产开发和生产不支持不支持
Windows开发和生产开发和生产不支持不支持
Mac OS X仅支持开发仅支持开发不支持不支持

对于矩阵中未明确提及支持的任何操作系统，组件可能工作，也可能不工作。ZooKeeper 社区会修复报告的其他平台上的明显错误，但没有完全的支持。

所需软件

ZooKeeper 运行在 Java 1.8 或更高版本（支持 JDK 8 LTS、JDK 11 LTS、JDK 12，不支持 Java 9 和 10）上。它作为 ZooKeeper 服务器的 集群（ensemble） 运行。一个集群建议的最小规模是三台 ZooKeeper 服务器，我们也建议它们运行在不同的机器上。在 Yahoo!，ZooKeeper 通常部署在专用的 RHEL 服务器上，配备双核处理器、2GB 内存和 80GB IDE 硬盘。

集群（多服务器）安装设置

为了获得可靠的 ZooKeeper 服务，您应该将 ZooKeeper 部署在称为 集群（ensemble） 的环境中。只要集群中的大多数服务器正常运行，服务就可用。由于 ZooKeeper 需要多数派，最好使用奇数台机器。例如，使用四台机器时，ZooKeeper 只能容忍一台机器的故障；如果两台机器发生故障，剩下的两台机器不构成多数派。然而，使用五台机器时，ZooKeeper 可以容忍两台机器的故障。

注意

如 ZooKeeper 入门指南 中所述，容错集群安装至少需要三台服务器，强烈建议您使用奇数台服务器。

通常三台服务器对于生产环境安装来说已经足够了，但为了在维护期间获得最高可靠性，您可能希望安装五台服务器。使用三台服务器时，如果您对其中一台进行维护，则在该维护期间很容易受到其他两台服务器中一台发生故障的影响。如果您有五台服务器正在运行，您可以停掉一台进行维护，并且知道即使其他四台中的一台突然出现故障，您也仍然没问题。

您的冗余考虑应该包括环境的所有方面。如果您有三台 ZooKeeper 服务器，但它们的网线都插入同一个网络交换机，那么该交换机的故障将导致整个集群瘫痪。

以下是设置集群中一个服务器的步骤。这些步骤应在集群中的每个主机上执行。

  1. 安装 Java JDK。您可以使用系统的原生包管理系统，或从以下地址下载 JDK：http://java.sun.com/javase/downloads/index.jsp

  2. 设置 Java 堆大小（heap size）。这一点非常重要，可以避免发生交换（swapping），交换会严重降低 ZooKeeper 的性能。要确定正确的值，请使用负载测试，并确保您远低于导致交换的使用限制。保守一些 - 对于 4GB 内存的机器，使用最大堆大小为 3GB。

  3. 安装 ZooKeeper 服务器软件包。可以从以下地址下载：https://zookeeper.net.cn/releases.html

  4. 创建一个配置文件。此文件可以命名为任何名称。使用以下设置作为起点：

    tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

    您可以在 配置参数 一节中找到这些及其他配置设置的含义。这里提一些注意事项：作为 ZooKeeper 集群一部分的每台机器都应该知道集群中的所有其他机器。您可以通过一系列形式为 server.id=host:port:port 的行来实现这一点。（参数 host 和 port 很直接，对于每台服务器，您需要先指定一个 Quorum 端口，然后指定一个用于 ZooKeeper 领导者选举的专用端口）。从 ZooKeeper 3.6.0 开始，您还可以为每个 ZooKeeper 服务器实例 指定多个地址（当集群中可以使用多个物理网络接口时，这可以提高可用性）。您通过创建一个名为 myid 的文件，为每台服务器指定一个服务器 ID，该文件位于该服务器的数据目录中，如配置文件参数 dataDir 所指定。

  5. myid 文件只包含该机器 ID 的一行文本，仅此而已。因此，服务器 1 的 myid 文件将只包含文本 "1"，没有其他内容。该 ID 在集群内必须是唯一的，且值应在 1 到 255 之间。重要： 如果启用扩展功能，例如 TTL 节点（见下文），由于内部限制，ID 必须在 1 到 254 之间。

  6. 在与 myid 文件相同的目录中创建一个初始化标记文件 initialize。此文件表示预期数据目录是空的。当此文件存在时，将创建一个空数据库并删除标记文件。当此文件不存在时，空的数据目录意味着该对等体将没有投票权，并且在与活动领导者通信之前不会填充数据目录。此文件的预期用途是仅在启动新的集群时创建它。

  7. 如果您的配置文件已设置好，您可以启动 ZooKeeper 服务器

    $ java -cp zookeeper.jar:lib/*:conf org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.conf

QuorumPeerMain 启动 ZooKeeper 服务器，同时也会注册 JMX 管理 MBean，这允许通过 JMX 管理控制台进行管理。ZooKeeper JMX 文档 中包含了使用 JMX 管理 ZooKeeper 的详细信息。请参阅发行版中包含的脚本 bin/zkServer.sh，以获取启动服务器实例的示例。8. 通过连接到主机来测试您的部署：在 Java 中，您可以运行以下命令来执行简单操作：

    $ bin/zkCli.sh -server 127.0.0.1:2181

单服务器和开发者安装设置

如果您想为开发目的设置 ZooKeeper，您可能希望设置一个 ZooKeeper 的单服务器实例，然后在您的开发机器上安装 Java 或 C 客户端库及绑定。

设置单服务器实例的步骤与上述类似，只是配置文件更简单。您可以在 ZooKeeper 入门指南 的 在单服务器模式下安装和运行 ZooKeeper 一节中找到完整的说明。

有关安装客户端库的信息，请参考 ZooKeeper 程序员指南 的 绑定 一节。

管理

本节包含有关运行和维护 ZooKeeper 的信息，涵盖以下主题

设计 ZooKeeper 部署方案

ZooKeeper 的可靠性基于两个基本假设。

  1. 部署中只有少数服务器会发生故障。这里的 故障（Failure） 指机器崩溃，或网络中将服务器与多数派隔离开来的错误。
  2. 部署的机器正常运行。正常运行意味着正确执行代码、时钟正常工作以及存储和网络组件性能稳定。

以下各节包含供 ZooKeeper 管理员参考的注意事项，以最大化这些假设成立的可能性。其中一些是跨机器考虑因素，另一些是您在部署中每台机器上都应该考虑的事项。

跨机器要求

为了使 ZooKeeper 服务处于活动状态，必须有大多数未发生故障且能够相互通信的机器。对于一个包含 N 个服务器的 ZooKeeper 集群，如果 N 是奇数，集群可以容忍高达 N/2 台服务器的故障而不会丢失任何 znode 数据；如果 N 是偶数，集群可以容忍高达 N/2-1 台服务器的故障。

例如，如果我们有一个包含 3 台服务器的 ZooKeeper 集群，它能够容忍高达 1 (3/2) 台服务器的故障。如果我们有一个包含 5 台服务器的 ZooKeeper 集群，它能够容忍高达 2 (5/2) 台服务器的故障。如果 ZooKeeper 集群有 6 台服务器，它也能容忍高达 2 (6/2-1) 台服务器的故障而不会丢失数据，并防止“脑裂”问题。

ZooKeeper 集群通常拥有奇数台服务器。这是因为对于偶数台服务器，容错能力与少一台服务器的集群相同（5 节点集群和 6 节点集群都容忍 2 台故障），但集群必须为多一台服务器维护额外的连接和数据传输。

为了实现容忍故障的最高可能性，您应该努力使机器故障相互独立。例如，如果大多数机器共享同一个交换机，那么该交换机的故障可能导致关联故障并使服务瘫痪。共享电源电路、冷却系统等也是如此。

单机器要求

如果 ZooKeeper 必须与其他应用程序争用存储介质、CPU、网络或内存等资源，其性能将显著下降。ZooKeeper 提供强大的持久性保证（durability guarantees），这意味着它在允许负责更改的操作完成之前，会使用存储介质记录更改日志。因此，您应该意识到这种依赖性，如果您想确保 ZooKeeper 操作不会被您的存储介质拖慢，请务必非常小心。以下是一些您可以采取的措施来最大程度地减少此类性能下降：

准备工作

注意事项：ZooKeeper 的优势和局限性

管理

维护

ZooKeeper 集群需要进行的长期维护很少，但是您必须了解以下事项：

持续的数据目录清理

ZooKeeper 的 数据目录 包含特定服务集群存储的 znodes 的持久副本文件。这些是快照文件和事务日志文件。当对 znodes 进行更改时，这些更改会被附加到事务日志中。有时，当日志文件变得很大时，会将所有 znodes 当前状态的快照写入文件系统，并为未来的事务创建一个新的事务日志文件。在生成快照期间，ZooKeeper 可能会继续将传入的事务附加到旧的日志文件中。因此，一些比快照新的事务可能会在紧接快照之前的最后一个事务日志中找到。

在使用默认配置时（参见下面的 autopurge），ZooKeeper 服务器不会删除旧的快照和日志文件，这是运维人员的责任。每个服务环境都不同，因此管理这些文件的要求可能因安装而异（例如备份）。

PurgeTxnLog 工具实现了管理员可以使用的简单保留策略。 API 文档 包含了调用约定（参数等）的详细信息。

在以下示例中，保留了最后 count 个快照及其对应的日志，其余的都被删除。此值的通常应大于 3（虽然不是强制要求，但这可以在最近日志损坏的极低概率事件中提供 3 个备份）。这可以作为 cron 作业在 ZooKeeper 服务器机器上运行，以每天清理日志。

java -cp zookeeper.jar:lib/slf4j-api-1.7.30.jar:lib/logback-classic-1.2.10.jar:lib/logback-core-1.2.10.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>

快照和相应事务日志的自动清除功能是在 3.4.0 版本中引入的，可以通过以下配置参数启用：autopurge.snapRetainCount 和 autopurge.purgeInterval。有关更多信息，请参阅下文的 高级配置。

调试日志清理 (logback)

请参阅本文档中关于 日志 的部分。预计您将使用内置的 logback 功能设置一个滚动文件附加器（rolling file appender）。发行版 tar 包的 conf/logback.xml 中的示例配置文件提供了这方面的示例。

进程守护

您会希望有一个监督进程来管理您的每个 ZooKeeper 服务器进程（JVM）。ZK 服务器被设计为“快速失败（fail fast）”，这意味着如果在发生无法恢复的错误时，它将关闭（进程退出）。由于 ZooKeeper 服务集群是高度可靠的，这意味着即使某个服务器可能宕机，整个集群仍然处于活动状态并处理请求。此外，由于集群具有“自愈（self healing）”能力，发生故障的服务器在重新启动后将自动重新加入集群，无需任何手动干预。

拥有一个监督进程，例如 daemontools 或 SMF（也有其他监督进程选项可用，使用哪一个取决于您，这些只是两个示例）来管理您的 ZooKeeper 服务器，可以确保如果进程异常退出，它将自动重新启动并快速重新加入集群。

此外，还建议配置 ZooKeeper 服务器进程，使其在发生 OutOfMemoryError** 时终止并转储（dump）其堆内存。这可以通过在 Linux 和 Windows 上分别使用以下参数启动 JVM 来实现。ZooKeeper 附带的 zkServer.sh 和 zkServer.cmd 脚本设置了这些选项。

-XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p'

"-XX:+HeapDumpOnOutOfMemoryError" "-XX:OnOutOfMemoryError=cmd /c taskkill /pid %%%%p /t /f"

监控

ZooKeeper 服务可以通过以下三种主要方式之一进行监控：

日志

ZooKeeper 使用 SLF4J 1.7 版本作为其日志记录基础设施。默认情况下，ZooKeeper 附带 LOGBack 作为日志记录后端，但您也可以使用任何其他受支持的日志记录框架。

ZooKeeper 默认的 logback.xml 文件位于 conf 目录中。Logback 要求 logback.xml 位于工作目录（ZooKeeper 运行所在的目录）或可从类路径（classpath）访问。

有关 SLF4J 的更多信息，请参阅 其手册。

有关 Logback 的更多信息，请参阅 Logback 网站。

故障排除

配置参数

ZooKeeper 的行为由 ZooKeeper 配置文件控制。此文件设计为，假设磁盘布局相同，集群中的所有服务器都可以使用完全相同的文件。如果服务器使用不同的配置文件，则必须谨慎确保所有不同配置文件中的服务器列表匹配。

注意

在 3.5.0 及更高版本中，其中一些参数应放置在动态配置文件中。如果它们被放置在静态配置文件中，ZooKeeper 将自动将其移动到动态配置文件中。有关更多信息，请参阅 动态重新配置。

基本配置

以下是必须在配置文件中定义的基本配置关键字：

高级配置

本节中的配置设置是可选的。您可以使用它们进一步微调（fine tune）ZooKeeper 服务器的行为。有些还可以使用 Java 系统属性（system properties）设置，通常形式为 zookeeper.keyword。如果可用，具体的系统属性将在下方注明。

此功能向后和向前兼容。以下是不同场景：

  1. a. 服务器内部触发的快照 当使用新代码加载旧快照时，尝试读取不存在的 lastProcessedZxid 值时会抛出 EOFException，该异常将被捕获。lastProcessedZxid 将使用快照文件名设置。

    b. 当使用旧代码加载新快照时，反序列化摘要值后将成功完成，快照文件末尾的 lastProcessedZxid 将被忽略。lastProcessedZxid 将使用快照文件名设置。

    1. Leader 和 Follower 之间的同步 在新旧代码中，lastProcessedZxid 都不会被 Leader 序列化和被 Follower 反序列化。它将被设置为 Leader 通过 QuorumPacket 发送的 lastProcessedZxid。

  2. 通过管理服务器 API 触发的快照 要使快照命令正常工作，需要启用此功能标志。

集群选项

本节中的选项设计用于服务器集群 -- 即部署服务器集群时使用。

如果你确实需要默认启用所有四字命令，可以使用星号选项，这样就不必在列表中逐个包含每个命令了。例如，这将启用所有四字命令：

4lw.commands.whitelist=*

加密、身份验证、授权选项

本节中的选项允许控制服务执行的加密/身份验证/授权。

除了此页面之外，你还可以在程序员指南中找到有关客户端配置的有用信息。ZooKeeper Wiki 上也有关于ZooKeeper SSL 支持和ZooKeeper 的 SASL 身份验证的有用页面。

实验性选项/功能

当前被认为是实验性的新功能。

不安全选项

以下选项可能有用，但使用时请小心。每个选项的风险与其变量功能的解释一同说明。

禁用数据目录自动创建

3.5 新增: ZooKeeper 服务器的默认行为是，如果在启动时数据目录（配置文件中指定）不存在，则自动创建该目录。这在某些情况下可能不方便甚至危险。以正在运行的服务器为例，如果配置更改中不小心更改了 dataDir 参数。当 ZooKeeper 服务器重新启动时，它将创建此不存在的目录并开始服务——使用空的 znode 命名空间。这种情况可能导致有效的 "脑裂"（split brain）局面（即新无效目录和原始有效数据存储中都有数据）。因此，最好有一个选项来关闭此自动创建行为。通常在生产环境中应该这样做，然而不幸的是，目前的默认遗留行为无法更改，因此必须逐案处理。这留给用户和 ZooKeeper 发行版打包者决定。

运行 zkServer.sh 时，可以通过将环境变量 ZOO_DATADIR_AUTOCREATE_DISABLE 设置为 1 来禁用自动创建。直接从类文件运行 ZooKeeper 服务器时，可以通过在 java 命令行上设置 zookeeper.datadir.autocreate=false 来实现，即 -Dzookeeper.datadir.autocreate=false

禁用此功能后，如果 ZooKeeper 服务器确定所需目录不存在，它将生成错误并拒绝启动。

提供了一个新脚本 zkServer-initialize.sh 以支持此新功能。如果禁用自动创建，用户需要首先安装 ZooKeeper，然后创建数据目录（以及可能的事务日志目录），然后启动服务器。否则，如上一段所述，服务器将不会启动。运行 zkServer-initialize.sh 将创建所需目录，并可选地设置 myid 文件（可选命令行参数）。即使不使用自动创建功能，也可以使用此脚本，这对用户可能有用，因为过去设置（包括创建 myid 文件）一直是用户面临的问题。请注意，此脚本仅确保数据目录存在，它不创建配置文件，但要求存在配置文件才能执行。

启用数据库存在性验证

3.6.0 新增: ZooKeeper 服务器在启动时找不到数据树的默认行为是将 zxid 设置为零并作为投票成员加入法定人数。如果服务器关闭期间发生某些事件（例如恶意的 'rm -rf'）删除了数据目录，这可能很危险，因为该服务器可能会帮助选举一个缺少事务的 Leader。启用数据库存在验证将改变启动时找不到数据树的行为：服务器将作为非投票参与者加入集群，直到它能够与 Leader 同步并获取集群数据的最新版本。为了表明预期的空数据树（集群创建），用户应将文件 'initialize' 放在与 'myid' 相同的目录中。此文件将在服务器启动时被检测到并删除。

直接从类文件运行 ZooKeeper 服务器时，可以通过在 java 命令行上设置 zookeeper.db.autocreate=false 来启用初始化验证，即 -Dzookeeper.db.autocreate=false。运行 zkServer-initialize.sh 将创建所需的初始化文件。

性能调优选项

3.5.0 新增: 多个子系统已重构，以提升读取吞吐量。这包括 NIO 通信子系统和请求处理管道（提交处理器）的多线程化。NIO 是默认的客户端/服务器通信子系统。它的线程模型包括 1 个接收器线程、1-N 个选择器线程和 0-M 个套接字 I/O 工作线程。在请求处理管道中，系统可以配置为同时处理多个读取请求，同时保持相同的一致性保证（同一会话的写后读）。提交处理器的线程模型包括 1 个主线程和 0-N 个工作线程。

默认值旨在最大限度地提高专用 ZooKeeper 机器上的读取吞吐量。这两个子系统都需要有足够的线程数量才能达到峰值读取吞吐量。

调试可观测性配置

3.6.0 新增: 引入以下选项使 ZooKeeper 更易于调试。

AdminServer 配置

3.9.0 新增: 以下选项用于配置 AdminServer。

3.7.1 新增: 以下选项用于配置 AdminServer。

3.6.0 新增: 以下选项用于配置 AdminServer。

3.5.0 新增: 以下选项用于配置 AdminServer。

指标提供者

3.6.0 新增: 以下选项用于配置指标。

默认情况下，ZooKeeper 服务器通过 AdminServer 和 四字命令 (Four Letter Words) 接口暴露有用的指标。

自 3.6.0 起，您可以配置不同的指标提供者，将指标导出到您喜欢的系统。

自 3.6.0 起，ZooKeeper 二进制包捆绑了与 Prometheus.io 的集成。

使用 Netty 框架进行通信

Netty 是一个基于 NIO 的客户端/服务器通信框架，它简化了（相比直接使用 NIO）Java 应用程序网络级通信的许多复杂性。此外，Netty 框架内置支持加密（SSL）和身份验证（证书）。这些是可选功能，可以单独开启或关闭。

在 3.5+ 版本中，ZooKeeper 服务器可以通过将环境变量 zookeeper.serverCnxnFactory 设置为 org.apache.zookeeper.server.NettyServerCnxnFactory 来使用 Netty 代替 NIO（默认选项）；对于客户端，将 zookeeper.clientCnxnSocket 设置为 org.apache.zookeeper.ClientCnxnSocketNetty。

Quorum TLS

3.5.5 新增

基于 Netty 框架，ZooKeeper 集群可以配置为在其通信通道中使用 TLS 加密。本节介绍如何在法定人数（Quorum）通信上设置加密。

请注意，法定人数 TLS 包括保护领导者选举和法定人数通信协议。

  1. 创建 SSL 密钥库 JKS 用于存储本地凭证

每个 ZK 实例应创建一个密钥库。

在此示例中，我们生成自签名证书并将其与私钥一起存储在 keystore.jks 中。这适用于测试目的，但在生产环境中，您可能需要官方证书来签署您的密钥。

请注意，别名（-alias）和可分辨名称（-dname）必须与关联机器的主机名匹配，否则主机名验证将不起作用。

keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
  1. 从密钥库中提取签名的公钥（证书）

此步骤可能仅对自签名证书必要。

keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc
  1. 创建包含所有 ZooKeeper 实例证书的 SSL 信任库 JKS

所有集群参与者应共享相同的信任库（存储所有接受的证书）。您需要在同一信任库中使用不同的别名来存储多个证书。别名的名称无关紧要。

keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password
  1. 您需要使用 NettyServerCnxnFactory 作为 serverCnxnFactory，因为 NIO 不支持 SSL。将以下配置设置添加到您的 zoo.cfg 配置文件中
sslQuorum=true
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.quorum.keyStore.location=/path/to/keystore.jks
ssl.quorum.keyStore.password=password
ssl.quorum.trustStore.location=/path/to/truststore.jks
ssl.quorum.trustStore.password=password
  1. 在日志中验证您的集群是否在 TLS 上运行
INFO  [main:QuorumPeer@1789] - Using TLS encrypted quorum communication
INFO  [main:QuorumPeer@1797] - Port unification disabled
...
INFO  [QuorumPeerListener:QuorumCnxManager$Listener@877] - Creating TLS-only quorum server socket

无需停机升级现有非 TLS 集群

3.5.5 新增

以下是利用端口统一功能将已运行的 ZooKeeper 集群升级到 TLS 而无需停机所需的步骤。

  1. 为所有 ZK 参与者创建所需的密钥库和信任库，如前一节所述

  2. 添加以下配置设置并重启第一个节点

sslQuorum=false
portUnification=true
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.quorum.keyStore.location=/path/to/keystore.jks
ssl.quorum.keyStore.password=password
ssl.quorum.trustStore.location=/path/to/truststore.jks
ssl.quorum.trustStore.password=password

请注意，TLS 尚未启用，但我们开启了端口统一。

  1. 在剩余节点上重复步骤 #2。验证您在日志中看到以下条目
INFO  [main:QuorumPeer@1791] - Using insecure (non-TLS) quorum communication
INFO  [main:QuorumPeer@1797] - Port unification enabled
...
INFO  [QuorumPeerListener:QuorumCnxManager$Listener@874] - Creating TLS-enabled quorum server socket

每次节点重启后，您还应再次检查法定人数（quorum）是否恢复正常。

  1. 在每个节点上启用法定人数 TLS 并进行滚动重启
sslQuorum=true
portUnification=true
  1. 一旦您验证了整个集群都在 TLS 上运行，就可以禁用端口统一并进行另一次滚动重启
sslQuorum=true
portUnification=false

ZooKeeper 命令

四字命令

ZooKeeper 会响应一小组命令。每个命令都由四个字母组成。您通过 telnet 或 nc 在客户端端口向 ZooKeeper 发出命令。

其中三个比较有趣的命令是："stat" 提供关于服务器和已连接客户端的一些通用信息，而 "srvr" 和 "cons" 分别提供服务器和连接的扩展详情。

3.5.3 新增: 四字命令在使用前需要明确列入白名单。详情请参阅集群配置部分中描述的 4lw.commands.whitelist。将来，四字命令将弃用，请改用AdminServer。

输出兼容 Java properties 格式，并且内容可能会随时间变化（会添加新键）。您的脚本应预期会有变化。注意：有些键是平台特定的，有些键仅由领导者（Leader）导出。输出包含多行，格式如下：

key \t value

以下是 ruok 命令的一个示例

$ echo ruok | nc 127.0.0.1 5111
    imok

AdminServer

3.5.0 新增: AdminServer 是一个内嵌的 Jetty 服务器，为四字命令提供 HTTP 接口。默认情况下，服务器在端口 8080 上启动，通过访问 URL "/commands/[command name]" 来发出命令，例如 http://localhost:8080/commands/stat。命令响应以 JSON 格式返回。与原始协议不同，命令不限于四字名称，并且命令可以有多个名称；例如，"stmk" 也可以称为 "set_trace_mask"。要查看所有可用命令列表，请在浏览器中访问 URL /commands（例如 http://localhost:8080/commands）。有关如何更改端口和 URL 的信息，请参阅AdminServer 配置选项。

AdminServer 默认启用，但可以通过以下方式禁用：

请注意，如果 AdminServer 被禁用，TCP 四字命令接口仍然可用。

为 AdminServer 配置 SSL/TLS
admin.portUnification=true
ssl.quorum.keyStore.location=/path/to/keystore.jks
ssl.quorum.keyStore.password=password
ssl.quorum.trustStore.location=/path/to/truststore.jks
ssl.quorum.trustStore.password=password

2019-08-03 15:44:55,213 [myid:] - INFO  [main:JettyAdminServer@123] - Successfully loaded private key from /data/software/cert/keystore.jks
2019-08-03 15:44:55,213 [myid:] - INFO  [main:JettyAdminServer@124] - Successfully loaded certificate authority from /data/software/cert/truststore.jks

2019-08-03 15:44:55,403 [myid:] - INFO  [main:JettyAdminServer@170] - Started AdminServer on address 0.0.0.0, port 8080 and command URL /commands

可用命令包括：

数据文件管理

ZooKeeper 将其数据存储在数据目录中，将其事务日志存储在事务日志目录中。默认情况下，这两个目录是相同的。服务器可以（也应该）配置为将事务日志文件存储在与数据文件分开的目录中。当事务日志位于专用日志设备上时，吞吐量会增加，延迟会降低。

数据目录

此目录中包含两到三个文件

每个 ZooKeeper 服务器都有一个唯一的 ID。此 ID 用于两个地方：myid 文件和配置文件。myid 文件标识对应给定数据目录的服务器。配置文件列出了由其服务器 ID 标识的每个服务器的联系信息。当 ZooKeeper 服务器实例启动时，它从 myid 文件中读取其 ID，然后使用该 ID 从配置文件中读取信息，查找应监听的端口。

存储在数据目录中的 snapshot 文件是模糊快照，因为在 ZooKeeper 服务器拍摄快照期间，数据树会发生更新。snapshot 文件名后缀是 zxid，即 ZooKeeper 事务 ID，是快照开始时最后提交事务的 ID。因此，快照包含在快照进行过程中发生的数据树更新的子集。因此，快照可能不对应于实际存在的任何数据树，因此我们将其称为模糊快照。尽管如此，ZooKeeper 仍可以使用此快照进行恢复，因为它利用了其更新的幂等性（idempotent nature）。通过对照模糊快照重放事务日志，ZooKeeper 可以获取日志结束时的系统状态。

日志目录

日志目录包含 ZooKeeper 事务日志。在进行任何更新之前，ZooKeeper 确保表示该更新的事务被写入非易失性存储。当写入当前日志文件的事务数量达到某个（可变）阈值时，将启动一个新的日志文件。阈值使用影响快照频率的相同参数计算（参见上面的 snapCount 和 snapSizeLimitInKb）。日志文件的后缀是写入该日志的第一个 zxid。

文件管理

快照和日志文件的格式在独立 ZooKeeper 服务器和不同配置的复制 ZooKeeper 服务器之间不会改变。因此，您可以将这些文件从正在运行的复制 ZooKeeper 服务器拉取到具有独立 ZooKeeper 服务器的开发机器上进行故障排除。

使用较旧的日志和快照文件，您可以查看 ZooKeeper 服务器的先前状态，甚至恢复该状态。

ZooKeeper 服务器创建快照和日志文件，但从不删除它们。数据和日志文件的保留策略是在 ZooKeeper 服务器外部实现的。服务器本身只需要最新的完整模糊快照、其后的所有日志文件以及其前的最后一个日志文件。后一个要求是必要的，以便包含在此快照开始后发生但在当时写入到现有日志文件中的更新。这是可能的，因为在 ZooKeeper 中，快照和日志滚动是相对独立进行的。有关设置保留策略和维护 ZooKeeper 存储的更多详情，请参阅本文档的维护部分。

注意

存储在这些文件中的数据未加密。如果在 ZooKeeper 中存储敏感数据，需要采取必要措施防止未经授权的访问。这些措施是 ZooKeeper 外部的（例如，控制对文件的访问），并取决于部署它的具体设置。

恢复 - TxnLogToolkit

更多详情可在此处找到。

应避免的事项

以下是一些通过正确配置 ZooKeeper 可以避免的常见问题。

最佳实践

为了获得最佳效果，请注意以下良好 ZooKeeper 实践列表

对于多租户安装，请参见详细介绍 ZooKeeper 的 "chroot" 支持的章节，这在部署许多对接单个 ZooKeeper 集群的应用程序/服务时会非常有用。