ZooKeeperManagement 员指南

部署和 Management 指南

• Deployment

• System Requirements

• Supported Platforms

  • Required Software

  • 群集(多服务器)设置

  • 单服务器和开发人员设置

• Administration

• 设计 ZooKeeper 部署

• 跨机要求

  • 单机要求

  • Provisioning

  • 要考虑的事情：ZooKeeper 的优势和局限性

  • Administering

  • Maintenance

• 正在进行的数据目录清除

  • 调试日志清除(log4j)

  • Supervision

  • Monitoring

  • Logging

  • Troubleshooting

  • Configuration Parameters

• Minimum Configuration

  • Advanced Configuration

  • Cluster Options

  • 加密，身份验证，授权选项

  • Experimental Options/Features

  • Unsafe Options

  • 禁用数据目录自动创建

  • 启用数据库存在验证

  • 性能调整选项

  • AdminServer configuration

  • 使用 Netty 框架进行通信

• Quorum TLS

  • 无需停机即可升级现有的非 TLS 群集

  • ZooKeeper Commands

• 四个字母的单词

  • The AdminServer

  • 资料 FilesManagement

• 数据目录

  • 日志目录

  • File Management

  • 恢复-TxnLogToolkit

  • 避免的事情

  • Best Practices

Deployment

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

• System Requirements

• 群集(多服务器)设置

• 单服务器和开发人员设置

前两个部分假设您对在生产环境(例如数据中心)中安装 ZooKeeper 感兴趣。最后一部分介绍了在有限的基础上设置 ZooKeeper(用于评估，测试或开发)但在生产环境中没有设置的情况。

System Requirements

Supported Platforms

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

• Client 是 JavaClient 端库，应用程序用来连接到 ZooKeeper 集成。

• 服务器 是在 ZooKeeper 集成节点上运行的 Java 服务器。

• Native Client 是用 C 实现的 Client 端，类似于 JavaClient 端，应用程序使用该 Client 端连接到 ZooKeeper 集成。

• Contrib 是指多个可选的附加组件。

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

Support Matrix

Operating System	Client	Server	Native Client	Contrib
GNU/Linux	开发生产	开发生产	开发生产	开发生产
Solaris	开发生产	开发生产	Not Supported	Not Supported
FreeBSD	开发生产	开发生产	Not Supported	Not Supported
Windows	开发生产	开发生产	Not Supported	Not Supported
Mac OS X	Development Only	Development Only	Not Supported	Not Supported

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

Required Software

ZooKeeper 运行于 Java 1.7 或更高版本(JDK 7 或更高版本，对 FreeBSD 的支持需要 openjdk7)。它作为 ZooKeeper 服务器的“整体”运行。建议三个最小的 ZooKeeper 服务器是一个整体的最小大小，我们也建议它们在单独的计算机上运行。在 Yahoo!上，ZooKeeper 通常部署在专用的 RHEL 盒上，该盒具有双核处理器，2GB RAM 和 80GB IDE 硬盘。

群集(多服务器)设置

为了获得可靠的 ZooKeeper 服务，您应该在称为* ensemble *的群集中部署 ZooKeeper。只要大多数合奏正常运行，就可以使用该服务。因为 Zookeeper 占多数，所以最好使用奇数台计算机。例如，对于四台机器，ZooKeeper 只能处理单台机器的故障；如果两台计算机发生故障，则其余两台计算机不占多数。但是，使用五台计算机，ZooKeeper 可以处理两台计算机的故障。

Note

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

• 安装 Java JDK。您可以将本机打包系统用于您的系统，也可以从以下位置下载 JDK：http://java.sun.com/javase/downloads/index.jsp

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

• 安装 ZooKeeper 服务器软件包。可以从以下网址下载：http://zookeeper.apache.org/releases.html

• 创建一个配置文件。这个文件可以叫任何东西。使用以下设置作为起点：

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

您可以在Configuration Parameters部分中找到这些以及其他配置设置的含义。这里只说几句：作为 ZooKeeper 合奏一部分的每台机器都应该知道该合奏中的每台其他机器。您可以通过一系列形式为 server.id = host：port：port 的行来完成此操作。参数 host 和 port 很简单。通过为服务器创建一个名为* myid *的文件，将服务器 ID 分配给每台计算机，该文件位于配置文件参数 dataDir 指定的该服务器数据目录中。

• myid 文件由仅包含该机器 ID 的文本的一行组成。因此，服务器 1 的* myid *将包含文本“ 1”，除此之外没有其他内容。 ID 在集合中必须是唯一的，并且值必须在 1 到 255 之间。 重要提示： 如果启用了 TTL 节点等扩展功能(请参见下文)，由于内部限制，ID 必须在 1 到 254 之间。

• 如果设置了配置文件，则可以启动 ZooKeeper 服务器：

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

QuorumPeerMain 启动了 ZooKeeper 服务器，还注册了JMXManagementbean，该 Managementbean 允许通过 JMXManagement 控制台进行 Management。 ZooKeeper JMX 文档包含有关使用 JMXManagementZooKeeper 的详细信息。有关启动服务器实例的示例，请参阅发行版中包含的脚本* bin/zkServer.sh *。

通过连接到主机来测试部署：在 Java 中，您可以运行以下命令来执行简单的操作：

$ bin/zkCli.sh -server 127.0.0.1:2181

单服务器和开发人员设置

如果要出于开发目的设置 ZooKeeper，则可能要设置 ZooKeeper 的单个服务器实例，然后在开发计算机上安装 Java 或 CClient 端库和绑定。

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

有关安装 Client 端库的信息，请参阅ZooKeeper 程序员指南的Bindings部分。

Administration

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

• 设计 ZooKeeper 部署

• Provisioning

• 要考虑的事情：ZooKeeper 的优势和局限性

• Administering

• Maintenance

• Supervision

• Monitoring

• Logging

• Troubleshooting

• Configuration Parameters

• ZooKeeper Commands

• 资料 FilesManagement

• 避免的事情

• Best Practices

设计 ZooKeeper 部署

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

• 部署中只有少数服务器将发生故障。在这种情况下，“故障”表示机器崩溃，或者是将服务器与大多数服务器分开的网络错误。

• 部署的计算机正常运行。正确操作意味着正确执行代码，使时钟正常工作以及使存储和网络组件一致运行。

以下各节包含 ZooKeeperManagement 员要考虑的因素，以最大程度地使这些假设成立。其中一些是跨计算机的考虑因素，而另一些则是部署中每台计算机应考虑的事项。

跨机器要求

为了使 ZooKeeper 服务处于活动状态，必须有大多数可以相互通信的非故障机器。要创建可以容忍 F 机故障的部署，您应该指望部署 2xF 1 机。因此，由三台计算机组成的部署可以处理一个故障，而由五台计算机组成的部署可以处理两个故障。请注意，部署六台计算机只能处理两个故障，因为三台计算机不是多数。因此，ZooKeeper 部署通常由奇数台计算机组成。

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

单机要求

如果 ZooKeeper 必须与其他应用程序竞争以访问诸如存储介质，CPU，网络或内存之类的资源，则其性能将显着下降。 ZooKeeper 具有很强的耐用性保证，这意味着在允许负责更改的操作完成之前，它使用存储介质记录更改。然后，您应该意识到这种依赖性，如果要确保媒体不阻止 ZooKeeper 的操作，请格外小心。您可以采取以下措施来最大程度地减少这种退化：

• ZooKeeper 的事务日志必须位于专用设备上。 (专用分区是不够的.)ZooKeeper 会按 Sequences 写入日志，而不进行查找。与其他进程共享日志设备会导致查找和争用，进而导致数秒的延迟。

• 不要将 ZooKeeper 放在可能引起交换的情况下。为了使 ZooKeeper 能够以任何及时性运行，它根本不能被交换。因此，请确保分配给 ZooKeeper 的最大堆大小不大于 ZooKeeper 可用的实际内存量。有关更多信息，请参见下面的避免的事情。

Provisioning

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

Administering

Maintenance

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

正在进行的数据目录清除

ZooKeeper Data Directory包含文件，这些文件是特定服务集合存储的 znode 的永久副本。这些是快照和事务日志文件。在对 znode 进行更改时，这些更改将附加到事务日志中。有时，当日志变大时，会将所有 znodes 当前状态的快照写入文件系统，并为将来的事务创建新的事务日志文件。在快照过程中，ZooKeeper 可能会 continue 将传入的事务追加到旧的日志文件中。因此，一些比快照新的事务可能会在快照之前的最后一个事务日志中找到。

当使用默认配置(请参阅下面的自动清除)时，ZooKeeper 服务器 不会删除旧快照和日志文件 ，这是操作员的责任。每个服务环境都不同，因此安装之间(例如备份)的 Management 这些文件的要求可能会有所不同。

PurgeTxnLogUtil 实现了 Management 员可以使用的简单保留策略。 API docs包含有关调用约定(参数等)的详细信息。

在以下示例中，将保留最后一个计数快照及其对应的日志，并删除其他快照。的值通常应大于 3(尽管不是必需的，但在最近的日志损坏的情况下，这可以提供 3 次备份)。这可以作为 ZooKeeper 服务器计算机上的 cron 作业运行，以每天清理日志。

java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.17.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>

自动清除快照和相应的事务日志是在 3.4.0 版中引入的，可以通过以下配置参数 autopurge.snapRetainCount 和 autopurge.purgeInterval 来启用。有关更多信息，请参见下面的Advanced Configuration。

调试日志清除(log4j)

请参阅本文档中关于logging的部分。期望您将使用内置的 log4j 功能来设置滚动文件追加程序。发行版 tar 的 conf/log4j.properties 中的 samples 配置文件提供了一个示例。

Supervision

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

拥有daemontools或SMF之类的监督流程(也可以使用其他监督程序选项，这取决于您要使用哪个，这只是两个示例)，对 ZooKeeper 服务器进行 Management 可以确保该过程确实退出时将自动重启并迅速重新加入集群。

还建议将 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"

Monitoring

ZooKeeper 服务可以通过以下两种主要方式之一进行监视： 1)通过使用4 个字母词的命令端口和 2)JMX。请参阅适合您的环境/要求的部分。

Logging

ZooKeeper 使用 SLF4J 版本 1.7.5 作为其日志记录基础结构。为了向后兼容，它绑定到 LOG4J ，但是您可以使用 LOGBack 或您选择的任何其他受支持的日志记录框架。

ZooKeeper 的默认* log4j.properties 文件位于 conf 目录中。 Log4j 要求 log4j.properties *可以在工作目录(运行 ZooKeeper 的目录)中，也可以从 Classpath 访问。

有关 SLF4J 的更多信息，请参见its manual。

有关 LOG4J 的更多信息，请参见 log4j 手册的Log4j 默认初始化过程。

Troubleshooting

• 由于文件损坏而导致服务器无法启动：服务器可能无法读取其数据库，并且由于 ZooKeeper 服务器的事务日志中的某些文件损坏而无法启动。您将在加载 ZooKeeper 数据库时看到一些 IOException。在这种情况下，请确保您集合中的所有其他服务器都已启动并正常工作。在命令端口上使用“ stat”命令查看它们是否健康。确认集成中的所有其他服务器都已启动后，可以 continue 清理损坏的服务器的数据库。删除 datadir/version-2 和 datalogdir/version-2 /中的所有文件。重新启动服务器。

Configuration Parameters

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

Note

Minimum Configuration

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

• • clientPort *：监听 Client 端连接的端口；即 Client 端尝试连接的端口。
• • secureClientPort *：用于侦听使用 SSL 的安全 Client 端连接的端口。 clientPort 指定用于纯文本连接的端口，而 secureClientPort 指定用于 SSL 连接的端口。同时指定两者都将启用混合模式，而省略其中任何一个将禁用该模式。请注意，当用户将 Zookeeper.serverCnxnFactory，zookeeper.clientCnxnSocket 插入为 Netty 时，将启用 SSL 功能。
• • dataDir *：ZooKeeper 将存储内存数据库快照的位置，除非另有说明，否则将存储数据库更新的事务日志。

Note

• • tickTime *：单个刻度的长度，这是 ZooKeeper 使用的基本时间单位，以毫秒为单位。它用于调节心跳和超时。例如，最小会话超时将是两个刻度。

Advanced Configuration

本节中的配置设置是可选的。您可以使用它们进一步调整 ZooKeeper 服务器的行为。也可以使用 Java 系统属性(通常为* zookeeper.keyword *形式)进行设置。可用时，确切的系统属性在下面列出。

• • dataLogDir * ：(无 Java 系统属性)此选项将指示机器将事务日志写入 dataLogDir 而不是 dataDir 。这允许使用专用的日志设备，并有助于避免日志记录和快照之间的竞争。

Note

• • globalOutstandingLimit * ：( Java 系统属性： zookeeper.globalOutstandingLimit. )，Client 端可以比 ZooKeeper 更快地提交请求，尤其是在有很多 Client 端的情况下。为了防止 ZooKeeper 由于队列中的请求而耗尽内存，ZooKeeper 会限制 Client 端，以便系统中的未完成请求不超过 globalOutstandingLimit。默认限制为 1,000.
• • preAllocSize *：(Java 系统属性： zookeeper.preAllocSize )为了避免查找，ZooKeeper 在事务日志文件中以 preAllocSize 千字节块的形式分配空间。默认块大小为 64M。更改块大小的原因之一是如果更频繁拍摄快照，则减小块大小。 (另请参见 snapCount )。
• • snapCount *：(Java 系统属性： zookeeper.snapCount )ZooKeeper 使用快照和一个事务日志(例如预写日志)记录其事务。可以在拍摄快照之前记录在事务日志中的事务数。 (以及已滚动的事务日志)由 snapCount 确定。为了防止仲裁中的所有计算机同时拍摄快照，当 Transaction 日志中的 Transaction 数量达到运行时生成的[snapCount/2 1]随机值时，每个 ZooKeeper 服务器都会拍摄快照。 snapCount]范围。默认的 snapCount 是 100,000.
• • maxClientCnxns * ：(无 Java 系统属性)将单个 Client 端(由 IP 地址标识)可以与 ZooKeeper 集成中的单个成员构建的并发连接数(在套接字级别)限制为多少。这用于防止某些类的 DoS 攻击，包括文件 Descriptors 耗尽。默认值为 60.将其设置为 0 将完全消除并发连接的限制。
• • clientPortAddress *： 3.3.0 中的新增功能： 用于侦听 Client 端连接的地址(ipv4，ipv6 或主机名)；即 Client 端尝试连接的地址。这是可选的，默认情况下，我们以这种方式绑定，即可以接受服务器上任何地址/接口/ NIC 到 clientPort 的任何连接。
• • minSessionTimeout * ：(无 Java 系统属性) 3.3.0 中的新增功能： 服务器允许 Client 端进行协商的最小会话超时(以毫秒为单位)。默认为 tickTime 的 2 倍。
• • maxSessionTimeout * ：(无 Java 系统属性) 3.3.0 中的新增内容： 服务器允许 Client 端进行协商的最大会话超时(以毫秒为单位)。默认为 tickTime 的 20 倍。
• • fsync.warningthresholdms *：(Java 系统属性： zookeeper.fsync.warningthresholdms ) 3.3.4 中的新增功能： 每当事务日志(WAL)中的 fsync 时，警告消息就会输出到日志花费的时间超过此值。该值以毫秒为单位指定，默认为 1000.只能将其设置为系统属性。
• • autopurge.snapRetainCount *：(无 Java 系统属性) 新的 3.4.0： 当启用时，动物园 Management 员自动清洗功能，保留了 **** autopurge.snapRetainCount 最近的快照和相应的事务日志中 dataDir 和 dataLogDir 并删除其余部分。默认值为 3.最小值为 3.
• • autopurge.purgeInterval *：(无 Java 系统属性) 3.4.0 中的新增功能： 必须触发清除任务的时间间隔(以小时为单位)。设置为正整数(1 或更大)以启用自动清除。预设为 0.
• • syncEnabled *：(Java 系统属性： zookeeper.observer.syncEnabled ) 3.4.6、3.5.0 中的新增功能： 观察者现在会像参与者一样记录事务并将快照默认写入磁盘。这减少了重新启动时观察者的恢复时间。设置为“ false”以禁用此功能。默认值为“ true”
• • zookeeper.extendedTypesEnabled *(Java 系统属性只有： **** zookeeper.extendedTypesEnabled) 新的 3.5.4： 定义为 “true” 启用扩展功能，如创建 TTL 节点。默认情况下禁用它们。重要信息：由于内部限制，启用的服务器 ID 必须小于 255.
• • zookeeper.emulate353TTLNodes *：(仅 Java 系统属性： zookeeper.emulate353TTLNodes ) 3.5.4 中的新增功能： 由于 ZOOKEEPER-2901,3.5.4 中不支持在 3.5.3 版中创建的 TTL 节点/3.6.0. 但是，可通过 zookeeper.emulate353TTLNodes 系统属性提供解决方法。如果您在 ZooKeeper 3.5.3 中使用了 TTL 节点，并且除了 zookeeper.extendedTypesEnabled 之外，还需要保持兼容性，请将 zookeeper.emulate353TTLNodes **设置为“ true”。注意：由于该错误，服务器 ID 必须小于或等于 127.此外，最大支持 TTL 值是 1099511627775，小于 3.5.3 中允许的值(1152921504606846975)
• • serverCnxnFactory * ：( Java 系统属性： zookeeper.serverCnxnFactory )指定 ServerCnxnFactory 实现。为了使用基于 TLS 的服务器通信，应将其设置为NettyServerCnxnFactory。默认值为NIOServerCnxnFactory。
• • snapshot.trust.empty *：(Java 系统属性： zookeeper.snapshot.trust.empty ) 3.5.6 中的新增功能： 此属性控制 ZooKeeper 是否应将丢失的快照文件视为致命文件无法恢复的状态。设置为 true 允许 ZooKeeper 服务器在没有快照文件的情况下恢复。仅应在从旧版本的 ZooKeeper(3.4.x，3.5.3 之前)进行升级期间进行设置，在该版本中，ZooKeeper 可能仅具有事务日志文件，而没有快照文件。如果在升级期间设置了该值，我们建议在升级后将该值重新设置为 false 并重新启动 ZooKeeper 进程，以便 ZooKeeper 可以在恢复过程中 continue 进行正常的数据一致性检查。默认值为 false。

Cluster Options

本节中的选项设计用于与一组服务器一起使用，即在部署服务器群集时。

• • electionAlg * ：(无 Java 系统属性)要使用的选举实现。值“ 1”对应于快速领导者选择的未经身份验证的基于 UDP 的版本，“ 2”对应于快速领导者的基于身份验证的 UDP 的版本，而“ 3”对应于快速领导者的基于 TCP 的版本选举。当前，算法 3 是默认算法。

Note

• • initLimit * ：(无 Java 系统属性)用于允许关注者连接并同步到领导者的时间(以滴答为单位)(请参见tickTime)。如果 ZooKeeperManagement 的数据量很大，请根据需要增加此值。
• • leaderServes * ：( Java 系统属性：zookeeper.leaderServes )Leader 接受 Client 端连接。默认值为“是”。领导机器协调更新。为了获得较高的更新吞吐量，而以读取吞吐量为代价，可以将领导者配置为不接受 Client 端，而专注于协调。此选项的默认值为“是”，这意味着领导者将接受 Client 端连接。

Note

• • server.x = [主机名]：nnnnn [：nnnnn]等* ：(无 Java 系统属性)构成 ZooKeeper 集合的服务器。服务器启动时，它通过在数据目录中查找文件* myid *来确定它是哪台服务器。该文件包含服务器号(以 ASCII 表示)，并且应与此设置左侧 server.x 中的 x 相匹配。Client 端使用的组成 ZooKeeper 服务器的服务器列表必须与每个 ZooKeeper 服务器具有的 ZooKeeper 服务器列表匹配。有两个端口号 nnnnn 。第一个跟随者用于连接领导者，第二个跟随者用于领导者选举。如果要在一台计算机上测试多个服务器，则可以为每个服务器使用不同的端口。
• • syncLimit * ：(无 Java 系统属性)允许跟踪者与 ZooKeeper 同步的时间(以滴答为单位)(请参见tickTime)。如果追随者远远落后于领导者，他们将被丢弃。
• • group.x = nnnnn [：nnnnn] * ：(无 Java 系统属性)启用分层仲裁。“ x”是组标识符，“ =”后的数字对应于服务器标识符。分配的左侧是用冒号分隔的服务器标识符列表。请注意，组必须是不相交的，并且所有组的并集必须是 ZooKeeper 集合。您会找到一个示例here
• • weight.x = nnnnn * ：(无 Java 系统属性)与“组”一起使用，它在形成仲裁时为服务器分配权重。该值对应于投票时服务器的权重。 ZooKeeper 的某些部分需要投票，例如领导人选举和原子 Broadcast 协议。默认情况下，服务器的权重为 1.如果配置定义了组，但没有定义权重，则将为所有服务器分配值 1.您会找到一个示例here
• • cnxTimeout * ：( Java 系统属性：zookeeper.cnxTimeout )设置打开领导者选举通知连接的超时值。仅在您使用选举算法 3 时适用。

Note

• • standaloneEnabled * ：(无 Java 系统属性) 3.5.0 中的新增功能： 设置为 false 时，可以以复制模式启动单个服务器，可以由观察者运行单个参与者，并且可以将集群重新配置为一个节点，然后从一个节点向上。为了向后兼容，默认值为 true。可以使用 QuorumPeerConfig 的 setStandaloneEnabled 方法或通过将“ standaloneEnabled = false”或“ standaloneEnabled = true”添加到服务器的配置文件中来进行设置。
• • reconfigEnabled * ：(无 Java 系统属性) 3.5.3 中的新增功能： 这控制启用或禁用Dynamic Reconfiguration功能。启用该功能后，假设用户被授权执行此类操作，则用户可以通过 ZooKeeperClient 端 API 或通过 ZooKeeper 命令行工具执行重新配置操作。禁用该功能后，包括超级用户在内的任何用户都无法执行重新配置。尝试重新配置将返回错误。可以将 “ reconfigEnabled” 选项设置为服务器配置文件的 “ reconfigEnabled = false” 或 “ reconfigEnabled = true” ，或使用 QuorumPeerConfig 的 setReconfigEnabled 方法。默认值为 false。如果存在，则该值在整个集合中的每个服务器上应保持一致。在某些服务器上将该值设置为 true，而在其他服务器上将该值设置为 false，则将导致不一致的行为，具体取决于哪个服务器被选为领导者。如果领导者的设置为 “ reconfigEnabled = true” ，则合奏将启用重新配置功能。如果领导者的设置为 “ reconfigEnabled = false” ，则该集成将禁用重新配置功能。因此，建议在整个服务器中的 “ reconfigEnabled” 具有一致的值。
• • 4lw.commands.whitelist * ：( Java 系统属性： zookeeper.4lw.commands.whitelist ) 3.5.3 中的新增功能： 用户要使用的逗号分隔的四个字母的单词命令列表。必须在此列表中 Importing 有效的四个字母的命令，否则 ZooKeeper 服务器将不会启用该命令。默认情况下，白名单仅包含 zkServer.sh 使用的“ srvr”命令。默认情况下，其余四个字母单词命令被禁用。这是启用 stat，ruok，conf 和 isro 命令同时禁用其余四个字母单词命令的配置示例：

4lw.commands.whitelist=stat, ruok, conf, isro

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

4lw.commands.whitelist=*

• • tcpKeepAlive * ：( Java 系统属性： zookeeper.tcpKeepAlive ) 3.5.4 中的新增功能： 将该属性设置为 true 会在仲裁成员用于执行选举的套接字上设置 TCP keepAlive 标志。当存在可能破坏仲裁成员的网络基础结构时，这将允许仲裁成员之间的连接保持连接状态。对于长时间运行或空闲的连接，某些 NAT 和防火墙可能会终止或丢失状态。启用此选项依赖于 os 级别的设置才能正常工作，有关更多信息，请检查 os 有关 TCP keepalive 的选项。默认为 false 。
• • electionPortBindRetry * ：(仅 Java 系统属性： zookeeper.electionPortBindRetry )该属性设置当 Zookeeper 服务器无法绑定领导者选举端口时的最大重试次数。此类错误可以是临时的和可恢复的(例如ZOOKEEPER-3320中描述的 DNS 问题)，也可以是不可重试的(例如已在使用的端口)。
    如果出现暂时性错误，此属性可以提高 Zookeeper 服务器的可用性并帮助其自我恢复。默认值 3.在容器环境中，尤其是在 Kubernetes 中，应增加该值或将其设置为 0(无限重试)，以解决与 DNS 名称解析有关的问题。

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

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

在此页面旁边，您还可以在Programmers Guide中找到有关 Client 端配置的有用信息。 ZooKeeper Wiki 还具有关于ZooKeeper SSL 支持和ZooKeeper 的 SASL 身份验证的有用页面。

• • DigestAuthenticationProvider.superDigest *：(Java 系统属性： zookeeper.DigestAuthenticationProvider.superDigest )默认情况下此功能是 禁用 3.2 中的新增功能： 允许 ZooKeeper 集成 Management 员以以下方式访问 znode 层次结构：一个“超级”用户。特别是，对于通过身份验证为超级的用户，不会进行 ACL 检查。 org.apache.zookeeper.server.auth.DigestAuthenticationProvider 可用于生成 superDigest，使用一个参数“ super：”对其进行调用。启动集成的每个服务器时，请提供生成的“ super：”作为系统属性值。当从 ZooKeeperClient 端向 ZooKeeper 服务器进行身份验证时，请传递“ digest”方案和“ super：”认证数据。请注意，摘要身份验证将明文形式的身份验证数据传递给服务器，因此，仅在 localhost(不通过网络)或加密连接上使用此身份验证方法是明智的。
• • X509AuthenticationProvider.superUser *：(Java 系统属性： zookeeper.X509AuthenticationProvider.superUser )SSL 支持的方法，使 ZooKeeper 集成 Management 员能够以“超级”用户身份访问 znode 层次结构。当此参数设置为 X500 主体名称时，只有具有该主体的经过身份验证的 Client 端将能够绕过 ACL 检查，并具有对所有 znode 的完全特权。
• • zookeeper.superUser * ：( Java 系统属性： zookeeper.superUser )类似于 zookeeper.X509AuthenticationProvider.superUser ，但对于基于 SASL 的登录名是通用的。它存储可以作为“超级”用户访问 znode 层次结构的用户名。
• • ssl.authProvider * ：( Java 系统属性： zookeeper.ssl.authProvider )指定 org.apache.zookeeper.auth.X509AuthenticationProvider 的子类用于安全 Client 端认证。这在不使用 JKS 的证书密钥基础结构中很有用。可能需要扩展 javax.net.ssl.X509KeyManager 和 javax.net.ssl.X509TrustManager 才能从 SSL 堆栈中获得所需的行为。要将 ZooKeeper 服务器配置为使用自定义提供程序进行身份验证，请为自定义 AuthenticationProvider 选择方案名称，并将属性 zookeeper.authProvider.[scheme] 设置为自定义实现的标准类名。这会将提供程序加载到 ProviderRegistry 中。然后设置此属性 zookeeper.ssl.authProvider = [scheme] ，该提供程序将用于安全身份验证。
• • sslQuorum * ：( Java 系统属性： zookeeper.sslQuorum ) 3.5.5 中的新增功能： 启用加密的仲裁通信。默认值为false。
• • ssl.keyStore.location 和 ssl.keyStore.password 和 ssl.quorum.keyStore.location 和 ssl.quorum.keyStore.password *：(Java 系统属性： zookeeper.ssl.keyStore.location 和 zookeeper.ssl.keyStore.pass 和 zookeeper.ssl.quorum.keyStore.location 和 zookeeper.ssl.quorum.keyStore.pass *)3.5.5 中的新功能： *指定 Java 密钥库的文件路径，其中包含要用于 Client 端和仲裁 TLS 连接的本地凭据，以及用于解锁文件的密码。
• • ssl.keyStore.type 和 ssl.quorum.keyStore.type ：(Java 系统属性： zookeeper.ssl.keyStore.type 和 zookeeper.ssl.quorum.keyStore.type ) * 3.5.5 中的新增功能：**指定 Client 端和仲裁密钥库的文件格式。值：JKS，PEM，PKCS12 或为空(按文件名检测)。
    Default: null
• • ssl.trustStore.location 和 ssl.trustStore.password 和 ssl.quorum.trustStore.location 和 ssl.quorum.trustStore.password *：(Java 系统属性： zookeeper.ssl.trustStore.location 和 zookeeper.ssl.trustStore.pass 和 zookeeper.ssl.quorum.trustStore.location 和 zookeeper.ssl.quorum.trustStore.pass ) 3.5.5 中的新增功能：**指定 Java 信任库的文件路径，该文件包含用于 Client 端和仲裁 TLS 连接的远程凭据以及用于解锁文件的密码。
• • ssl.trustStore.type 和 ssl.quorum.trustStore.type ：(Java 系统属性： zookeeper.ssl.trustStore.type 和 zookeeper.ssl.quorum.trustStore.type ) * 3.5.5 中的新增功能：**指定 Client 端和仲裁 trustStores 的文件格式。值：JKS，PEM，PKCS12 或为空(按文件名检测)。
    Default: null
• • ssl.protocol 和 ssl.quorum.protocol ：(Java 系统属性： zookeeper.ssl.protocol 和 zookeeper.ssl.quorum.protocol )* 3.5.5 中的新增功能：* *指定要在 Client 端和仲裁 TLS 协商中使用的协议。默认值：TLSv1.2
• • ssl.enabledProtocols 和 ssl.quorum.enabledProtocols ：(Java 系统属性： zookeeper.ssl.enabledProtocols 和 zookeeper.ssl.quorum.enabledProtocols )* 3.5.5 中的新增功能：* *指定 Client 端和仲裁 TLS 协商中启用的协议。默认值：protocol属性的值
• • ssl.ciphersuites 和 ssl.quorum.ciphersuites ：(Java 系统属性： zookeeper.ssl.ciphersuites 和 zookeeper.ssl.quorum.ciphersuites )* 3.5.5 中的新增功能：* *指定在 Client 端和仲裁 TLS 协商中使用的已启用密码套件。默认值：启用的密码套件取决于所使用的 Java 运行时版本。
• • ssl.context.supplier.class 和 ssl.quorum.context.supplier.class *：(Java 系统属性： zookeeper.ssl.context.supplier.class 和 zookeeper.ssl.quorum.context .supplier.class ) 3.5.5 中的新增功能： 指定用于在 Client 端和仲裁 SSL 通信中创建 SSL 上下文的类。这使您可以使用自定义 SSL 上下文并实现以下方案：

• 使用通过 PKCS11 或类似工具加载的硬件密钥库。

• 您无权访问软件密钥库，但可以从其容器中检索已经构造的 SSLContext。默认值：空

• • ssl.hostnameVerification 和 ssl.quorum.hostnameVerification ：(Java 系统属性： zookeeper.ssl.hostnameVerification 和 zookeeper.ssl.quorum.hostnameVerification )* 3.5.5 中的新增功能：* *指定是否在 Client 端和仲裁 TLS 协商过程中启用主机名验证。仅建议出于测试目的禁用它。默认值：true
• • ssl.crl 和 ssl.quorum.crl ：(Java 系统属性： zookeeper.ssl.crl 和 zookeeper.ssl.quorum.crl )* 3.5.5 中的新增功能：* *指定是否在 Client 端和仲裁 TLS 协议中启用证书吊销列表。默认值：false
• • ssl.ocsp 和 ssl.quorum.ocsp ：(Java 系统属性： zookeeper.ssl.ocsp 和 zookeeper.ssl.quorum.ocsp )* 3.5.5 中的新增功能：* *指定是否在 Client 端和仲裁 TLS 协议中启用了“在线证书状态协议”。默认值：false
• • ssl.clientAuth 和 ssl.quorum.clientAuth ：(Java 系统属性： zookeeper.ssl.clientAuth 和 zookeeper.ssl.quorum.clientAuth )* 3.5.5 中的新增功能：* *待定
• • ssl.handshakeDetectionTimeoutMillis 和 ssl.quorum.handshakeDetectionTimeoutMillis ：(Java 系统属性： zookeeper.ssl.handshakeDetectionTimeoutMillis 和 zookeeper.ssl.quorum.handshakeDetectionTimeoutMillis )* 3.5.5 中的新增功能：* *待定
• • client.portUnification *：(Java 系统属性： zookeeper.client.portUnification ) 3.5.7 的新增功能 指定 Client 端端口应接受 SSL 连接(使用与安全 Client 端端口相同的配置) 。默认值：false
• • authProvider * ：( Java 系统属性： zookeeper.authProvider )您可以为 ZooKeeper 指定多个身份验证提供程序类。通常，您使用此参数来指定 SASL 身份验证提供程序，例如：authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
• • kerberos.removeHostFromPrincipal *(Java 系统属性： zookeeper.kerberos.removeHostFromPrincipal )您可以指示 ZooKeeper 在身份验证期间从 Client 端主体名称中删除主机。 (例如，zk/myhost @ EXAMPLE.COMClient 端主体将在 ZooKeeper 中通过身份验证为 [email protected])默认值：false
• • kerberos.removeRealmFromPrincipal *(Java 系统属性： zookeeper.kerberos.removeRealmFromPrincipal )您可以指示 ZooKeeper 在身份验证期间从 Client 端主体名称中删除领域。 (例如，zk/myhost @ EXAMPLE.COMClient 端主体将在 ZooKeeper 中被验证为 zk/myhost)默认值：false

Experimental Options/Features

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

• 只读模式服务器：(Java 系统属性： readonlymode.enabled ) 3.4.0 中的新增功能： 将该值设置为 true 可启用只读模式服务器支持(默认情况下禁用)。 ROM 允许请求 ROM 支持的 Client 端会话连接到服务器，即使服务器可能已从定额分区。在这种模式下，ROMClient 端仍可以从 ZK 服务读取值，但是将无法写入值并查看其他 Client 端的更改。有关更多详细信息，请参见 ZOOKEEPER-784.

Unsafe Options

以下选项可能有用，但是在使用它们时要小心。解释每个变量的风险以及变量作用的解释。

• • forceSync * ：( Java 系统属性： zookeeper.forceSync )在完成更新处理之前，需要将更新同步到事务日志的媒体。如果此选项设置为 no，则 ZooKeeper 将不需要将更新同步到媒体。
• • jute.maxbuffer：* ：( Java 系统属性： jute.maxbuffer )此选项只能设置为 Java 系统属性。上面没有 Zookeeper 前缀。它指定可以存储在 znode 中的数据的最大大小。默认值为 0xfffff，或不到 1M。如果更改此选项，则必须在所有服务器和 Client 端上设置系统属性，否则会出现问题。这确实是一个健全性检查。 ZooKeeper 旨在存储大小为千字节的数据。
• • jute.maxbuffer.extrasize *(Java 系统属性： **** zookeeper.jute.maxbuffer.extrasize) 新的 3.5.7： 在处理 Client 端请求的 ZooKeeper 服务器增加了一些额外的信息放入坚持之前的请求作为 Transaction。之前，此附加信息的大小固定为 1024 字节。对于许多情况，特别是 jute.maxbuffer 值大于 1 MB 并且请求类型为多的情况，此固定大小是不够的。为了处理所有情况，其他信息大小从 1024 字节增加到与 jute.maxbuffer 大小相同，并且可以通过 jute.maxbuffer.extrasize 对其进行配置。通常，由于默认值是最佳值，因此不需要配置此属性。
• • skipACL * ：( Java 系统属性： zookeeper.skipACL )跳过 ACL 检查。这样可以提高吞吐量，但是每个人都可以完全访问数据树。
• • quorumListenOnAllIPs *：设置为 true 时，ZooKeeper 服务器将在所有可用 IP 地址上侦听来自其对等方的连接，而不仅仅是在配置文件的服务器列表中配置的地址。它影响处理 ZAB 协议和快速领导者选举协议的连接。默认值为 false 。

禁用数据目录自动创建

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

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

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

提供了一个新脚本 zkServer-initialize.sh 以支持此新功能。如果禁用了自动创建，则用户必须首先安装 ZooKeeper，然后创建数据目录(可能还有 txnlog 目录)，然后启动服务器。否则，如前一段所述，服务器将无法启动。运行 zkServer-initialize.sh 将创建所需的目录，并可选地设置 myid 文件(可选的命令行参数)。即使不使用自动创建功能本身，也可以使用此脚本，并且该脚本可能已被用户使用，因为过去(用户设置(包括创建 myid 文件))已经成为问题。请注意，此脚本确保数据目录仅存在，它不会创建配置文件，而是需要一个配置文件才能执行。

性能调整选项

3.5.0 中的新增功能： 已对多个子系统进行了改进，以提高读取吞吐量。这包括 NIO 通信子系统和请求处理管道(Commit Processor)的多线程。 NIO 是默认的 Client 端/服务器通信子系统。它的线程模型包括 1 个接收器线程，1-N 个 selectors 线程和 0-M 个套接字 I/O 工作线程。在请求处理管道中，系统可以配置为一次处理多个读取请求，同时保持相同的一致性保证(相同的会话写入后读取)。提交处理器线程模型包括 1 个主线程和 0-N 个工作线程。

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

• • zookeeper.nio.numSelectorThreads * ：(仅 Java 系统属性： zookeeper.nio.numSelectorThreads ) 3.5.0 中的新增功能： NIOselectors 线程数。至少需要 1 个 selectors 线程。对于大量的 Client 端连接，建议使用多个 selectors。默认值为 sqrt(cpu 核心数/ 2)。
• • zookeeper.nio.numWorkerThreads * ：(仅 Java 系统属性： zookeeper.nio.numWorkerThreads ) 3.5.0 中的新增功能： NIO 工作线程数。如果配置了 0 个工作线程，则 selectors 线程直接执行套接字 I/O。默认值为 cpu 核心数的 2 倍。
• • zookeeper.commitProcessor.numWorkerThreads * ：(仅 Java 系统属性： zookeeper.commitProcessor.numWorkerThreads ) 3.5.0 中的新增功能： 提交处理器工作线程的数量。如果配置了 0 个工作线程，则主线程将直接处理请求。默认值为 cpu 核心数。
• • znode.container.checkIntervalMs *：(仅适用于 Java 系统属性) 3.5.1 中的新增功能： 候选容器和 ttl 节点的每次检查的时间间隔(以毫秒为单位)。默认值为“ 60000”。
• • znode.container.maxPerMinute *：(仅 Java 系统属性) 3.5.1 中的新增功能： 每分钟可以删除的容器和 ttl 节点的最大数量。这样可以防止在删除容器时放牧。默认值为“ 10000”。

AdminServer configuration

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

• • admin.enableServer * ：( Java 系统属性： zookeeper.admin.enableServer )设置为“ false”以禁用 AdminServer。默认情况下，AdminServer 是启用的。
• • admin.serverAddress * ：( Java 系统属性： zookeeper.admin.serverAddress )嵌入式 Jetty 服务器侦听的地址。默认为 0.0.0.0.
• • admin.serverPort * ：( Java 系统属性： zookeeper.admin.serverPort )嵌入式 Jetty 服务器侦听的端口。默认为 8080
• • admin.idleTimeout * ：( Java 系统属性： zookeeper.admin.idleTimeout )设置连接在发送或接收数据之前可以 await 的最大空闲时间(以毫秒为单位)。默认为 30000 毫秒
• • admin.commandURL * ：( Java 系统属性： zookeeper.admin.commandURL )相对于根 URL 列出和发布命令的 URL。默认为“/commands”。

使用 Netty 框架进行通信

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

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

Quorum TLS

• 3.5.5 的新功能*

基于 Netty Framework，可以将 ZooKeeper 集成设置为在其通信通道中使用 TLS 加密。本节介绍如何在仲裁通信中设置加密。

请注意，Quorum TLS 封装了确保领导者选举和法定通信协议的安全。

• 创建 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

• 从密钥库中提取签名的公钥(证书)

仅对自签名证书才需要执行此步骤.

keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc

• 创建包含所有 ZooKeeper 实例证书的 SSL 信任库 JKS

同一信任库(存储所有接受的证书)应在集合的参与者之间共享。您需要使用不同的别名将多个证书存储在同一信任库中。别名的名称无关紧要。

keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password

• 您需要使用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

• 在日志中验证您的集成正在 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 所需的步骤。

• 如上一节所述，为所有 ZK 参与者创建必要的密钥库和信任库

• 添加以下配置设置并重新启动第一个节点

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，但我们打开了端口统一。

• 在其余节点上重复步骤 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 TLS 并进行滚动重启：

sslQuorum=true portUnification=true

• 验证整个集成在 TLS 上运行后，您可以禁用端口统一并再次滚动重启

sslQuorum=true portUnification=false

ZooKeeper Commands

四个字母词

ZooKeeper 响应少量命令。每个命令由四个字母组成。您可以在 Client 端端口通过 telnet 或 nc 向 ZooKeeper 发出命令。

三个更有趣的命令：“ stat”提供有关服务器和连接的 Client 端的一些常规信息，而“ srvr”和“ cons”分别提供有关服务器和连接的扩展详细信息。

3.5.3 中的新增功能： 使用前，必须将四个字母词明确列出为白色。有关详细信息，请参阅集群配置部分中描述的 4lw.commands.whitelist 。展望 Future，不建议使用四个字母词，请改用AdminServer。

• • conf *： 3.3.0 中的新增功能： 打印有关服务配置的详细信息。
• • cons *： 3.3.0 中的新增功能： 列出连接到此服务器的所有 Client 端的完整连接/会话详细信息。包括有关接收/发送的数据包数量，会话 ID，操作 await 时间，上次执行的操作等信息。
• • crst *： 3.3.0 中的新增功能： 重置所有连接的连接/会话统计信息。
• • dump *：列出未完成的会话和临时节点。这仅适用于领导者。
• • envi *：打印有关服务环境的详细信息
• • ruok *：测试服务器是否在非错误状态下运行。如果服务器正在运行，它将以 imok 响应。否则它将完全不响应。响应“ imok”不一定表示服务器已加入仲裁，只是服务器进程处于活动状态并绑定到指定的 Client 端端口。使用“ stat”获取有关状态仲裁和 Client 端连接信息的详细信息。
• • srst *：重置服务器统计信息。
• • srvr *： 3.3.0 中的新增功能： 列出服务器的完整详细信息。
• • stat *：列出服务器和连接的 Client 端的简短详细信息。
• • wchs *： 3.3.0 中的新增功能： 列出有关服务器监视的简要信息。
• • wchc *： 3.3.0 中的新增功能： 按会话列出有关服务器监视的详细信息。这将输出具有相关监视(路径)的会话(连接)列表。请注意，根据手表数量的不同，此操作可能会很昂贵(即影响服务器性能)，请小心使用。
• • dirs *： 3.5.1 中的新增功能： 以字节为单位显示快照和日志文件的总大小
• • wchp *： 3.3.0 中的新增功能： 按路径列出有关服务器监视的详细信息。这将输出具有关联会话的路径(znode)列表。请注意，根据手表数量的不同，此操作可能会很昂贵(即影响服务器性能)，请小心使用。
• • mntr *： 3.4.0 中的新增功能： 输出可用于监视集群运行状况的变量列表。

$ echo mntr | NClocalhost2185 zk_version 3.4.0 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 70 zk_packets_sent 69 个 zk_num_alive_connections 1 个 zk_outstanding_requests 0 zk_server_state 前导 zk_znode_count 4 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 27 个 zk_followers 4 - 仅由组长 zk_synced_followers 4 露出 - 仅由组长 zk_pending_syncs 0 暴露 - 仅由领导者公开 zk_open_file_descriptor_count 23-仅在 Unix 平台上可用 zk_max_file_descriptor_count 1024-仅在 Unix 平台上可用 zk_last_proposal_size 23 zk_min_proposal_size 23 zk_max_proposal_size 64

输出与 Java 属性格式兼容，并且内容可能会随时间变化(添加了新键)。您的脚本应该会有变化。注意：一些密钥是特定于平台的，而某些密钥仅由 Leader 导出。输出包含具有以下格式的多行：

key \t value

• • isro *： 3.4.0 中的新增功能： 测试服务器是否以只读模式运行。如果服务器处于只读模式，则服务器将以“ ro”响应；如果不是只读模式，则服务器将以“ rw”响应。
• • gtmk *：以十进制格式获取当前的跟踪掩码，作为 64 位带符号的 long 值。有关可能的值的说明，请参见stmk。
• • stmk *：设置当前的跟踪掩码。跟踪掩码为 64 位，其中每个位启用或禁用服务器上特定类别的跟踪日志记录。必须将 Log4J 配置为首先启用TRACE级别，才能查看跟踪日志记录消息。跟踪掩码的位对应于以下跟踪日志记录类别。

跟踪掩码位值
0b0000000000	未使用，保留以备将来使用。
0b0000000010	记录 Client 端请求，但不包括 ping 请求。
0b0000000100	未使用，保留以备将来使用。
0b0000001000	记录 Client 端 ping 请求。
0b0000010000	记录从作为当前领导者的仲裁对等方收到的数据包，但不包括 ping 请求。
0b0000100000	记录 Client 端会话的添加，删除和验证。
0b0001000000	记录监视事件到 Client 端会话的传递。
0b0010000000	记录从作为当前领导者的仲裁对等方收到的 ping 数据包。
0b0100000000	未使用，保留以备将来使用。
0b1000000000	未使用，保留以备将来使用。

64 位值中的所有其余位均未使用，并保留以供将来使用。通过计算记录值的按位或，可以指定多个跟踪日志记录类别。默认跟踪掩码为 0b0100110010.因此，默认情况下，跟踪日志记录包括 Client 端请求，从领导者接收的数据包和会话。要设置其他跟踪掩码，请发送一个请求，该请求包含stmk个四个字母的单词，后跟跟踪掩码，表示为一个 64 位带符号的 long 值。本示例使用 Perl pack函数构造一个跟踪掩码，该掩码启用上述所有跟踪日志记录类别，并将其转换为具有 big-endian 字节 Sequences 的 64 位有符号 long 值。结果将附加到stmk并使用 netcat 发送到服务器。服务器以十进制格式响应新的跟踪掩码。

$ perl -e“打印'stmk'，pack('q>'，0b0011111010)” | nclocalhost2181 250

这是 ruok 命令的示例：

$ echo ruok | nc 127.0.0.1 5111
    imok

The 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 默认情况下处于启用状态，但可以通过以下任一方式禁用：

• 将 zookeeper.admin.enableServer 系统属性设置为 false。

• 从 Classpath 中删除 Jetty。 (如果您想覆盖 ZooKeeper 的 Jetty 依赖性，则此选项很有用.)

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

数据文件 Management

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

数据目录

此目录中包含两个或三个文件：

• • myid *-在人类可读的 ASCII 文本中包含一个表示服务器 ID 的整数。
• • initialize *(初始化)-存在表示预期缺少数据树。创建数据树后清除。

• *快照-保存数据树的模糊快照。

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

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

日志目录

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

File Management

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

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

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

Note

恢复-TxnLogToolkit

TxnLogToolkit 是 ZooKeeper 附带的命令行工具，能够恢复带有损坏 CRC 的事务日志条目。

在不使用任何命令行参数或不使用-h,--help参数的情况下运行它，它将输出以下帮助页面：

$ bin/zkTxnLogToolkit.sh
usage: TxnLogToolkit [-dhrv] txn_log_file_name
-d,--dump      Dump mode. Dump all entries of the log file. (this is the default)
-h,--help      Print help message
-r,--recover   Recovery mode. Re-calculate CRC for broken entries.
-v,--verbose   Be verbose in recovery mode: print all entries, not just fixed ones.
-y,--yes       Non-interactive mode: repair all CRC errors without asking

默认行为是安全的：将给定事务日志文件的条目转储到屏幕上：(与使用-d,--dump参数相同)

$ bin/zkTxnLogToolkit.sh log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
4/5/18 2:15:58 PM CEST session 0x16295bafcc40000 cxid 0x0 zxid 0x100000001 createSession 30000
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:12 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x100000003 createSession 30000
4/5/18 2:17:34 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x200000001 closeSession null
4/5/18 2:17:34 PM CEST session 0x16295bd23720000 cxid 0x0 zxid 0x200000002 createSession 30000
4/5/18 2:18:02 PM CEST session 0x16295bd23720000 cxid 0x2 zxid 0x200000003 create '/andor,#626262,v{s{31,s{'world,'anyone}}},F,1
EOF reached after 6 txns.

上面的事务日志文件的第二个条目中有一个 CRC 错误。在 转储 模式下，该工具包仅将此信息打印到屏幕上，而无需触摸原始文件。在“恢复”模式(-r,--recover标志)下，原始文件仍然保持不变，所有事务将被复制到后缀为“ .fixed”的新 txn 日志文件中。如果它与原始 txn 条目不匹配，它将重新计算 CRC 值并复制计算出的值。默认情况下，该工具以交互方式工作：遇到 CRC 错误时，它会要求进行确认。

$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ?

回答“是”表示新计算的 CRC 值将输出到新文件。 否 表示将复制原始的 CRC 值。 中止 将中止整个操作并退出。 (在这种情况下，“.fixed”将不会被删除，并处于半完成状态：仅包含已经处理过的条目，或者如果操作在第一个条目中止，则仅包含 Headers.)

$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ? y
EOF reached after 6 txns.
Recovery file log.100000001.fixed has been written with 1 fixed CRC error(s)

恢复的默认行为是保持沉默：仅将带有 CRC 错误的条目打印到屏幕上。可以使用-v,--verbose参数打开详细模式以查看所有记录。可以使用-y,--yes参数关闭交互模式。在这种情况下，所有 CRC 错误都将在新的事务文件中修复。

应避免的事情

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

• 服务器列表不一致：Client 端使用的 ZooKeeper 服务器列表必须与每个 ZooKeeper 服务器具有的 ZooKeeper 服务器列表匹配。如果 Client 端列表是真实列表的子集，则一切正常，但如果 Client 端具有位于不同 ZooKeeper 群集中的 ZooKeeper 服务器列表，则事情真的会很奇怪。另外，每个 Zookeeper 服务器配置文件中的服务器列表应彼此一致。

• Transaction 日志的放置不正确：ZooKeeper 的性能最关键的部分是 Transaction 日志。 ZooKeeper 在返回响应之前将事务同步到媒体。专用的事务日志设备是保持良好性能的关键。将日志放在繁忙的设备上会对性能产生不利影响。如果只有一个存储设备，则将跟踪文件放在 NFS 上，并增加 snapshotCount;它不能消除问题，但可以减轻它。

• • Java 堆大小不正确*：您应该特别注意正确设置 Java 最大堆大小。特别是，您不应创建 ZooKeeper 交换到磁盘的情况。磁盘对 ZooKeeper 来说是死亡。一切都是有序的，因此，如果处理一个请求交换了磁盘，则所有其他排队的请求可能也会执行相同的操作。磁盘。不要交换。保守估计：如果您有 4G RAM，请不要将 Java 最大堆大小设置为 6G 甚至 4G。例如，您更有可能在 4G 计算机上使用 3G 堆，因为 os 和缓存也需要内存。估计系统所需堆大小的最佳建议方法是运行负载测试，然后确保您的使用率远低于导致系统交换的使用限制。

• 可公开访问的部署：ZooKeeper 集成有望在受信任的计算环境中运行。因此，建议将 ZooKeeper 部署在防火墙后面。

Best Practices

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

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