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 服务器的集群运行。三个 ZooKeeper 服务器是集群的最小推荐大小，我们还建议它们在不同的机器上运行。在雅虎，ZooKeeper 通常部署在专用的 RHEL 机箱上，具有双核处理器、2GB RAM 和 80GB IDE 硬盘。

集群（多服务器）设置

对于可靠的 ZooKeeper 服务，您应该将 ZooKeeper 部署在称为集群的集群中。只要集群中的大多数可用，服务就会可用。由于 Zookeeper 需要大多数，因此最好使用奇数台机器。例如，对于四台机器，ZooKeeper 只能处理一台机器的故障；如果两台机器发生故障，剩余的两台机器不构成大多数。但是，对于五台机器，ZooKeeper 可以处理两台机器的故障。

注意

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

通常情况下，三台服务器对于生产安装来说已经足够了，但为了在维护期间获得最大的可靠性，您可能希望安装五台服务器。对于三台服务器，如果您对其中一台服务器执行维护，则在维护期间容易受到其他两台服务器之一发生故障的影响。如果您运行五台服务器，则可以关闭一台进行维护，并且知道如果其他四台服务器之一突然发生故障，您仍然没事。

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

以下是设置将成为集合一部分的服务器的步骤。这些步骤应在集合中的每个主机上执行

  1. 安装 Java JDK。你可以为你的系统使用本机打包系统，或从以下位置下载 JDK：http://java.sun.com/javase/downloads/index.jsp

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

  3. 安装 ZooKeeper 服务器包。可以从以下位置下载：http://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 非常简单，对于每台服务器，你需要首先指定一个仲裁端口，然后指定一个用于 ZooKeeper leader 选举的专用端口）。自 ZooKeeper 3.6.0 以来，你还可以为每个 ZooKeeper 服务器实例指定多个地址（当集群中可以并行使用多个物理网络接口时，这可以提高可用性）。你将服务器 ID 归因于每台机器，方法是创建一个名为 myid 的文件，每个服务器一个，该文件驻留在该服务器的数据目录中，如配置文件参数 dataDir 所指定。

  5. myid 文件由单行组成，仅包含该机器 ID 的文本。因此，服务器 1 的 myid 将包含文本“1”和无其他内容。ID 在集合中必须是唯一的，并且应该在 1 到 255 之间。重要提示：如果你启用扩展功能（例如 TTL 节点）（见下文），则由于内部限制，ID 必须在 1 到 254 之间。

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

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

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

QuorumPeerMain 启动一个 ZooKeeper 服务器，JMX 管理 Bean 也已注册，允许通过 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. 部署中的服务器中只有少数会发生故障。在此上下文中，“故障”意味着机器崩溃，或网络中导致服务器与大多数服务器分区的某些错误。
  2. 已部署的机器正常运行。正常运行意味着正确执行代码，拥有正常工作的时钟，以及拥有持续执行存储和网络组件。

以下部分包含 ZooKeeper 管理员为最大程度提高这些假设成立的可能性而考虑的事项。其中一些是跨机器考虑因素，而另一些是您应该为部署中的每台机器考虑的事项。

跨机器要求

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

例如，如果我们有一个包含 3 台服务器的 ZooKeeper 集群，则该集群最多可以容忍 1（3/2）台服务器故障。如果我们有一个包含 5 台服务器的 ZooKeeper 集群，则该集群最多可以容忍 2（5/2）台服务器故障。如果包含 6 台服务器的 ZooKeeper 集群，则该集群最多可以容忍 2（6/2-1）台服务器故障，而不会丢失数据并防止“脑裂”问题。

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

要实现容错的最高概率，您应该尝试使机器故障独立。例如，如果大多数机器共享同一交换机，则该交换机的故障可能会导致相关故障并使服务中断。共享电源电路、冷却系统等也适用此规则。

单机要求

如果 ZooKeeper 必须与其他应用程序争用对存储介质、CPU、网络或内存等资源的访问，则其性能将显著下降。ZooKeeper 具有强大的持久性保证，这意味着它使用存储介质来记录更改，然后才允许对更改负责的操作完成。因此，您应该意识到这种依赖性，并且如果您想确保 ZooKeeper 操作不会因您的介质而中断，则应格外小心。以下是一些可以采取的措施来最大程度地减少此类性能下降

供应

需要考虑的事项：ZooKeeper 的优势和局限性

管理

维护

ZooKeeper 集群几乎不需要长期维护，但您必须注意以下事项

正在进行的数据目录清理

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

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

PurgeTxnLog 实用程序实施了管理员可以使用的一个简单保留策略。API 文档 包含有关调用约定（参数等）的详细信息。

在以下示例中，保留了最后计数的快照及其对应的日志，并删除了其他快照。 的值通常应大于 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 功能设置一个滚动文件追加器。发行版 tar 文件中的示例配置文件 conf/logback.xml 提供了一个示例。

监督

您需要一个监督进程来管理您的每个 ZooKeeper 服务器进程 (JVM)。ZK 服务器设计为“快速失败”，这意味着如果发生无法恢复的错误，它将关闭（进程退出）。由于 ZooKeeper 服务集群高度可靠，这意味着虽然服务器可能会宕机，但集群作为一个整体仍然处于活动状态并提供服务。此外，由于集群是“自愈”的，因此一旦重新启动，故障服务器将自动重新加入集合，而无需任何手动交互。

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

还建议将 ZooKeeper 服务器进程配置为在发生 OutOfMemoryError** 时终止并转储其堆。这可以通过在 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 的目录）中或可从类路径访问。

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

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

故障排除

配置参数

ZooKeeper 的行为受 ZooKeeper 配置文件控制。此文件的目的是，假设磁盘布局相同，则构成 ZooKeeper 服务器的所有服务器都可以使用完全相同的文件。如果服务器使用不同的配置文件，则必须小心确保所有不同配置文件中的服务器列表匹配。

注意

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

最小配置

以下是必须在配置文件中定义的最小配置关键字

高级配置

本部分中的配置设置是可选的。你可以使用它们来进一步微调 ZooKeeper 服务器的行为。有些还可以使用 Java 系统属性设置，通常为 zookeeper.keyword 形式。如果有的话，确切的系统属性会在下面注明。

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

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

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

    1. 领导者和跟随者之间的同步 lastProcessedZxid 将不会在新旧代码中由领导者序列化，也不会由跟随者反序列化。它将设置为通过 QuorumPacket 从领导者发送的 lastProcessedZxid。

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

集群选项

本节中的选项旨在与服务器集成一起使用，即在部署服务器集群时使用。

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

4lw.commands.whitelist=*

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

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

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

实验选项/特性

当前被视为实验性质的新功能。

不安全选项

以下选项可能有用，但使用时请小心。每种风险都会在解释变量作用时进行说明。

禁用数据目录自动创建

3.5 新特性：ZooKeeper 服务器的默认行为是在启动时自动创建数据目录（在配置文件中指定），如果该目录不存在。在某些情况下，这可能不方便，甚至很危险。以对正在运行的服务器进行配置更改为例，其中 dataDir 参数被意外更改。当 ZooKeeper 服务器重新启动时，它将创建此不存在的目录并开始提供服务 - 其中 znode 命名空间为空。此场景可能导致有效的“脑裂”情况（即新无效目录和原始有效数据存储中的数据）。因此，最好有一个选项来关闭此自动创建行为。通常对于生产环境应该这样做，但不幸的是，默认的旧行为此时无法更改，因此必须逐案进行。这留给用户和 ZooKeeper 发行版的打包者。

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

当此功能被禁用，并且 ZooKeeper 服务器确定所需的目录不存在时，它将生成一个错误并拒绝启动。

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

启用数据库存在性验证

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

通过在 Java 命令行上设置 zookeeper.db.autocreate=false，即 -Dzookeeper.db.autocreate=false，可以启用初始化验证，直接从类文件运行 ZooKeeper 服务器。运行 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。

法定人数 TLS

3.5.5 中的新增功能

基于 Netty 框架，ZooKeeper 组件可以设置在通信通道中使用 TLS 加密。本部分介绍如何在仲裁通信中设置加密。

请注意，仲裁 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

您还应在每次重新启动节点后仔细检查仲裁是否再次变为正常。

  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 属性格式兼容，并且内容可能会随着时间的推移而改变（添加新键）。您的脚本应预期更改。注意：某些键是特定于平台的，而某些键仅由领导者导出。输出包含多行，格式如下

key \t value

以下是 ruok 命令的示例

$ echo ruok | nc 127.0.0.1 5111
    imok

AdminServer

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

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

请注意，如果禁用了 AdminServer，TCP 四字母单词接口仍然可用。

可用命令包括

数据文件管理

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

数据目录

此目录中有两个或三个文件

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

数据目录中存储的快照文件是模糊快照，因为在 ZooKeeper 服务器获取快照期间，数据树正在更新。快照文件名的后缀是zxid，即快照开始时最后提交的事务的 ZooKeeper 事务 ID。因此，快照包括在快照处理过程中发生的数据树更新的子集。然后，快照可能与实际存在的任何数据树不对应，因此我们将其称为模糊快照。尽管如此，ZooKeeper 仍然可以使用此快照进行恢复，因为它利用了其更新的幂等性。通过针对模糊快照重播事务日志，ZooKeeper 获取日志末尾的系统状态。

日志目录

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

文件管理

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

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

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

注意

存储在这些文件中的数据未加密。在 ZooKeeper 中存储敏感数据时，需要采取必要的措施来防止未经授权的访问。此类措施在 ZooKeeper 之外（例如，控制对文件的访问）并且取决于其部署的各个设置。

恢复 - TxnLogToolkit

更多详细信息可在此处找到

需要避免的事项

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

最佳实践

为了获得最佳结果，请注意以下 Zookeeper 良好做法列表

对于多租户安装，请参阅详细说明 ZooKeeper “chroot” 支持的部分，这在将许多应用程序/服务部署到单个 ZooKeeper 集群时非常有用。