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 服务器是集群的最小推荐大小，我们还建议它们在不同的机器上运行。在 Yahoo!，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 服务器实例指定多个地址（当集群中可以并行使用多个物理网络接口时，这可以提高可用性）。您可以通过创建名为 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 管理 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 个备份）。这可以在 ZooKeeper 服务器机器上作为 cron 作业运行，以每天清理日志。

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. 在 leader 和 follower 之间同步 lastProcessedZxid 将不会在新的和旧代码中由 leader 序列化，也不会由 follower 反序列化。它将被设置为通过 QuorumPacket 从 leader 发送的 lastProcessedZxid。

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

集群选项

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

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

4lw.commands.whitelist=*

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

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

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

实验选项/功能

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

不安全选项

以下选项可能有用，但使用时请小心。每个选项的风险在变量功能说明中进行了说明。

禁用数据目录自动创建

ZooKeeper 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”相同的目录中。此文件将在启动时被服务器检测到并删除。

直接从类文件运行 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 的客户端/服务器通信框架，它简化了 Java 应用程序中网络级通信的许多复杂性（直接使用 NIO）。此外，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. 在每个节点上启用 Quorum 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/[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 从配置文件中读取，查找它应该监听的端口。

存储在数据目录中的快照文件是模糊快照，因为在 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 集群时非常有用。