Apache > ZooKeeper
 
 

ZooKeeper 管理员指南

部署和管理指南

部署

本节包含有关部署 Zookeeper 的信息并涵盖以下主题：

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

系统要求

支持的平台

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

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

支持矩阵
操作系统客户服务器本机客户端贡献
GNU/Linux开发和生产开发和生产开发和生产开发和生产
索拉里斯开发和生产开发和生产不支持不支持
自由BSD开发和生产开发和生产不支持不支持
视窗开发和生产开发和生产不支持不支持
Mac OS X仅开发仅开发不支持不支持

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

所需软件

ZooKeeper 在 Java 1.8 或更高版本中运行（JDK 8 LTS、JDK 11 LTS、JDK 12 - 不支持 Java 9 和 10）。它作为ZooKeeper 服务器的集合运行。三个 ZooKeeper 服务器是 ensemble 的最小推荐大小，我们还建议它们在单独的机器上运行。在 Yahoo!，ZooKeeper 通常部署在专用的 RHEL 机器上，具有双核处理器、2GB RAM 和 80GB IDE 硬盘驱动器。

集群（多服务器）设置

对于可靠的 ZooKeeper 服务，您应该将 ZooKeeper 部署在称为ensemble的集群中。只要大多数合奏都启动了，该服务就可以使用。因为 Zookeeper 需要多数，所以最好使用奇数台机器。例如，有四台机器的 ZooKeeper 只能处理单台机器的故障；如果两台机器发生故障，剩下的两台机器不构成多数。但是，使用五台机器 ZooKeeper 可以处理两台机器的故障。

笔记

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

通常三台服务器对于生产安装来说绰绰有余，但为了在维护期间获得最大的可靠性，您可能希望安装五台服务器。对于三台服务器，如果您对其中一台执行维护，那么在维护期间您很容易在其他两台服务器中的一台上发生故障。如果您有五个正在运行，您可以将其中一个停机进行维护，并且知道如果其他四个中的一个突然出现故障，您仍然可以。

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

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

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

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

  3. 安装 ZooKeeper 服务器包。可从以下网址下载：http: //zookeeper.apache.org/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 在 ensemble 中必须是唯一的，并且应该具有介于 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) 个服务器故障。如果 ZooKeeper ensemble 具有 6 个服务器，则该 ensemble 还能够容忍多达 2 (6/2-1) 个服务器故障而不会丢失数据并防止“脑裂”问题。

ZooKeeper ensemble 通常有奇数个服务器。这是因为对于偶数的服务器，容错能力与少一台服务器的 ensemble 相同（5 节点 ensemble 和 6 节点 ensemble 都发生 2 次故障），但 ensemble 必须保持额外的连接和多台服务器的数据传输。

为了最大程度地容忍故障，您应该尝试使机器故障独立。例如，如果大多数机器共享同一个交换机，则该交换机的故障可能会导致相关故障并导致服务中断。共享电源电路、冷却系统等也是如此。

单机要求

如果 ZooKeeper 必须与其他应用程序竞争访问存储介质、CPU、网络或内存等资源，其性能将受到显着影响。ZooKeeper 具有强大的持久性保证，这意味着它在负责更改的操作被允许完成之前使用存储介质记录更改。你应该意识到这种依赖关系，如果你想确保 ZooKeeper 操作不会被你的媒体阻止，请务必小心。您可以采取以下措施来最大程度地减少这种退化：

供应

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

管理

维护

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

正在进行的数据目录清理

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

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

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 服务器可确保如果进程确实异常退出，它将自动重新启动并快速重新加入集群。

如果发生 OutOfMemoryError**，还建议配置 ZooKeeper 服务器进程以终止并转储其堆。这是通过分别在 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形式。确切的系统属性（如果可用）如下所示。

集群选项

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

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

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”）在服务器关闭时删除了数据目录，这可能会很危险，因为该服务器可能会帮助选举缺少事务的领导者。启用 db 存在验证将在未找到数据树时更改启动时的行为：服务器作为非投票参与者加入 ensemble，直到它能够与领导者同步并获取最新版本的 ensemble 数据. 为了指示预期的空数据树（集成创建），用户应将文件“initialize”放在与“myid”相同的目录中。该文件将在启动时被服务器检测并删除。

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

性能调整选项

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

默认值旨在最大化专用 ZooKeeper 机器上的读取吞吐量。两个子系统都需要有足够数量的线程来实现峰值读取吞吐量。

调试可观察性配置

3.6.0 中的新功能：引入了以下选项以使 zookeeper 更易于调试。

管理服务器配置

3.7.1 中的新功能：以下选项用于配置AdminServer。

3.6.0 中的新功能：以下选项用于配置AdminServer。

3.5.0 中的新功能：以下选项用于配置AdminServer。

指标提供者

3.6.0 中的新功能：以下选项用于配置指标。

默认情况下，ZooKeeper 服务器使用AdminServer公开有用的指标。和四个字母单词界面。

从 3.6.0 开始，您可以配置不同的 Metrics Provider，将指标导出到您喜欢的系统。

自 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 加密。本节介绍如何在仲裁通信上设置加密。

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

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

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. 在日志中验证您的 ensemble 是否在 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. 一旦你确认你的整个 ensemble 都在 TLS 上运行，你可以禁用端口统一并再次滚动重启
sslQuorum=true
portUnification=false

动物园管理员命令

四个字母的单词

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

管理服务器

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 四字母单词接口仍然可用。

可用的命令包括：

数据文件管理

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 集群时非常有用。