| dataLogDir | 该参数有默认值: dataDir，可以不配置，不支持系统属性方式配置。参数 dataLogDir 用于配置 ZooKeeper 服务器存储事务日志文件的目录。默认情况下，ZooKeeper 会将事务日志文件和快照数据存储在同一目录中，应该尽量将这两者的牧区区分开来。另外，如果条件允许，可以将事务日志的存储位置配置在一个单独的磁盘上。事务日志记录对于磁盘的性能要求非常高，为了保证数据的一致性，ZooKeeper 在返回客户端事务请求相应之前，必须将本次请求对应的事务日志写入到磁盘中。因此，事务日志写入的性能直接决定了 ZooKeeper 在处理事务请求时的吞吐。针对同一块磁盘的其他并发读写操作（例如 ZooKeeper 运行时日志输出和操作系统自身的读写等），尤其是数据快照操作，会极大地影响事务日志的写性能。因此尽量给事务日志的输出配置一个单独的磁盘或挂载点，将极大地提升 ZooKeeper 的整体性能。 |
| initLimit | 该参数有默认值: 10，即表示是参数 tickTime 值得10倍，必须配置，且需要配置一个正整数，不支持系统属性方式配置。该参数用于配置 Leader 服务器等待 Follower 启动，并完成数据同步的时间。Follwer 服务器再启动过程中，会与 Leader 建立连接并完成对数据的同步，从而确定自己对外提供服务的其实状态。Leader 服务器允许 Follower 在 initLimit 时间内完成这个工作。 通常情况下，运维人员不用太在意这个参数的配置，使用默认值即可。但如果随着 ZooKeeper 集群管理的数据量增大，Follower 服务器再启动的时候，从 Leader 上进行同步数据的时间也会相应变长，于是无法在较短的时间完成数据同步。因此，在这种情况下，有必要适当调大这个参数。 |
| syncLimit | 该参数有默认值: 5，即表示参数 tickTime 值得5倍，必须配置，且需要配置一个正整数，不支持系统属性配置。该参数用于配置 Leader 服务器和 Follower 服务器之间进行心跳检测的最大延时时间。在 ZooKeeper 集群运行过程中，Leader 服务器会与所有的 Follower 进行心跳检测来确定该服务器是否存活。如果 Leader 服务器再 syncLimit 时间内无法获取到 Follower 的心跳检测响应，那么 Leader 就会认为该 Follower 已经脱离了和自己的同步。通常情况下，运维人员使用该参数的默认值即可，但如果部署ZooKeeper 集群的网络环境质量较低（例如网络延时较大或丢包严重），那么可以适当调大这个参数。 |
| snapCount | 该参数有默认值: 1000，可以不配置，仅支持系统属性方式配置 zookeeper.snapCount。参数 snapCount 用于配置相邻2次数据快照之间的事务操作次数，即 ZooKeeper 会在 snapCount 次事务操作之后进行一次数据快照。 |
| preAllocSize | 该参数有默认值: 65536，单位是 KB，即64MB，可以不配置，仅支持系统属性方式配置: zookeeper.preAllocSize。参数 preAllocSize 用于配置 ZooKeeper 事务日志文件预分配的磁盘空间大小。通常情况下，使用 ZooKeeper 的默认配置 65536KB 即可，但是如果我们将参数 snapCount设置得比默认值更小或更大，那么 preAllocSize 参数也要随之做出变更。举个例子来说: 如果我们将 snapCount 的值设置为 500，同时预估每次事务操作的数据量大小至多 1KB，那么参数 preAllocSize 设置为 500就足够了。 |
| minSessionTimeout、maxSessionTimeout | 这2个参数有默认值，分别是参数 tickTime 值的2倍和20倍，即默认的会话超时时间在 2 * tickTime ~ 20 * tickTime 范围内，单位为毫秒，可以不配置，不支持系统属性配置。这2个参数用于服务端对客户端会话的超时时间进行限制，如果客户端设置的超时时间不在该范围内，那么会被服务端强制设置为最大或最小超时时间。 |
| maxClientCnxns | 该参数有默认值: 60，可以不配置，不支持系统属性方式配置。从 Socket 层面限制单个客户端与单台服务器之间的并发连接数，即以 IP 地址粒度来进行连接数的限制。如果将该参数设置为0，则表示对连接不做任何限制。需要注意的是该连接数限制选项的使用范围仅仅是对单台客户端机器与单台 ZooKeeper 服务器之间的连接数限制，并不能控制所有客户端的连接数总和。在 3.4.0 版本以前该参数的默认值都是 10，从 3.4.0 版本开始变成了 60，因此运维人员需要注意这个变化，以防 ZooKeeper 版本变化带来服务端连接数限制变化的隐患。 |
| jute.maxbuffer | 该参数有默认值: 1048575，单位是字节，可以不配置，仅支持系统属性方式配置: jute.maxbuffer。该参数用于配置单个数据节点(ZNode)上可以存储的最大数据量大小。通常情况下，运维人员不需要改动该参数，同时考虑到 ZooKeeper 上不适宜存储太多的数据，往往还需要将该参数设置的更小。需要注意的是，在变更该参数的时候，需要在 ZooKeeper 集群的所有机器以及所有的客户端上均设置才能生效。 |
| clientPortAddress | 该参数没有默认值，可以不配置，不支持系统属性配置。针对那些多网卡的机器，该参数允许为每个 IP 地址指定不同的监听端口。 |
| server.id=host:port:port | 该参数没有默认值，在单机模式下可以不配置，不支持系统属性配置。该参数用于配置组成 ZooKeeper 集群的机器列表，其中 id 即为 Server ID，与每台服务器 myid 文件中的数字相对应。同时，在该参数中会配置2个端口，第一个端口用于指定 Follower 服务器与 Leader 进行运行时通信和数据同步时所使用的端口，第二个端口则专门用于进行 Leader 选举过程中的投票通信。在 ZooKeeper 服务启动的时候，其会根据 myid 文件中配置的 Server ID来确定自己是那台服务器，并使用对应配置的端口来进行启动。如果在实际使用过程中，需要在同一台服务器上部署多个 ZooKeeper 示例来构成伪集群的话，那么这些端口都需要配置成不通过如: server.1=192.168.o.1:2777:3777 server.1=192.168.o.1:2888:3888 server.1=192.168.o.1:2999:3999 |
| autopurge.snapRetainCount | 该参数有默认值: 3，可以不配置，不支持系统属性配置。从 3.4.0 版本开始，ZooKeeper 提供了对历史事务日志和快照数据自动清理的支持。参数 autopurge.snapRetainCount 用于配置 ZooKeeper 在自动清理的时候需要保留的快照数据文件数量和对应的事务日志文件。需要注意的是，并不是磁盘上的所有事务日志和快照数据文件都可以被清理掉—那样的话将无法恢复数据。因此参数 autopurge.snapRetainCount 的最小值是 3，如果配置的 autopurge.snapRetainCount 值比 3 小的话，那么会被自动调整到 3，即至少需要保留3个快照数据文件和对应的事务日志文件。 |
| autopurge.purgeInterval | 该参数有默认值: 0，单位是小时，可以不配置，不支持系统属性配置。参数 autopurge.purgeInterval 和参数 autopurge.snapRetainCount 配套使用，同于配置 ZooKeeper 进行历史文件自动清理的频率。如果配置该值为 0或负数，那么就表明不需要开启定时清理功能。ZooKeeper 默认不开启这项功能。 |
| fsync.warningthresholdms | 该参数有默认值: 1000，单位是毫秒，可以不配置，仅支持系统属性方式配置: fsync.warningthresholdms。参数 fsync.warningthresholdms 用于配置 ZooKeeper 进行事务日志 fsync 操作时消耗时间的报警阈值。一旦进行一个 fsync 操作消耗的时间大于参数 fsync.warningthresholdms 指定的值，那么就在日志中打印出报警日志。 |
| forceSync | 该参数有默认值: yes，可以不配置，可选配置项为”yes” 和 “no”，仅支持系统属性配置: zookeeper.forceSync。该参数用于配置 ZooKeeper 服务器是否在事务提交的时候，将日志写入操作强制刷入磁盘（即调用 java.nio.channels.FileChannel.force 接口），默认情况下是“yes”，即每次事务日志写入操作都会实时刷入磁盘。如果将其设置为“no”，则能一定程度的提高ZooKeeper 的写性能，但同时也会存在类似于机器断电这样的安全风险。 |
| globalOutstandingLimit | 该参数有默认值: 1000，可以不配置，仅支持系统属性方式配置: zookeeper.globalOutstandingLimit。参数 globalOutstandingLimit 用于配置 ZooKeeper 服务器最大请求堆积数量。在 ZooKeeper 服务器运行的过程中，客户端会源源不断的请求发送到服务器，为了防止服务器资源（包括 CPU、内存和网络等）耗尽，服务端必须限制同时处理的请求数，即最大请求堆积数量。 |
| leaderServers | 该参数有默认值: yes，可以不配置，可选配置项为”yes” 和 “no”，仅支持系统属性方式配置: zookeeper.leaderServers。该参数用于配置 Leader 服务器是否能够接受客户端的连接，即是否允许 Leader 想客户端提供服务，默认情况下，Leader 服务器能够接受并处理客户端的所有读写请求。在 ZooKeeper 的架构设计中，Leader 服务器主要用来进行实物更新请求的协调以及集群本省运行时协调，因此，可以设置让 Leader 服务器不接受客户端的连接，以使其专注于进行分布式协调。 |
| skipAcl | 该参数有默认值: no，可以不配置，可选配置项为”yes” 和 “no”，仅支持系统属性方式配置: zookeeper.skipAcl。该参数用于配置 ZooKeeper 服务器是否跳过 ACL 权限检查，默认情况下是”no”，即会对每一次客户端请求进行权限检查。如果将其设置为”yes”，则能一定程度的提高 ZooKeeper 的读写性能，单同时也将向所有客户端开放 ZooKeeper 的数据，包括那些之前设置过 ACL 权限的数据节点，也将不在接受权限控制。 |
| cnxTimeout | 该参数有默认值: 5000，单位是毫秒，可以不设置，仅支持系统属性方式配置: zookeeper.cnxTimeout。该参数用于配置在 Leader 选举过程中，如服务器之间进行 TCP 连接创建的超时时间。 |
| electionAlf | 在之前的版本中，可以使用该参数来配置选择 ZooKeeper 进行 Leader 选举时所使用的算法，但从 3.4.0 版本开始，ZooKeeper 废弃了其他选举算法，只留下 FastLeaderElection 算法，因此该参数目前看来没有用了。 |
