本文涵盖了更多的高级配置，包括了standalone模式和ensemble模式。不设置它们也能让ZooKeeper工作得很好，但是其中的一些应该需要好好配置一些(比如dataLogDir)。
preAllocSize
为每个事务日志文件预分配(preallocate)的大小，单位为kilobyte。(zookeeper.preAllocSize)
当开始写事务日志时，server每次都会分配这个配置项指定的大小的磁盘块。这样可以为文件系统减轻负担，这样就不用在更新元数据或者追加日志文件空间不够时申请新的磁盘块了。更重要的是，它最小化磁盘寻道的次数。
默认此配置项是64M。如果日志文件不会变得更大的话，可以减少这个配置项的值。因为在每一个快照结束时会开始生成一个新的日志文件，如果在两次快照的间隔期间的那个事务日志大小达不到64M的话，那么需要调低这个值，以免造成空间浪费。例如，如果我们每执行1000个事务就生成一次快照，一个事务的大小 平均为100字节，那么把preAllocSize配置成100KB就更合适。默认的preAllocSize的值对于“默认的snapCount值，事务大小 平均值大于512字节”的情况是适用的。
snapCount
在两次事务快照之间可执行事务的次数(zookeeper.snapCount)。
当一个ZooKeeper进程服务重启时，它需要恢复之前的状态。这里有2个关于时间的关键因素，一个是读取快照文件花费的时间，另一个是重做快照文件开始生成之后的事务日志的花费时间。经常做一下快照可以减少重做的事务日志的数据量。然而，做快照会对服务的性能有一定影响，即使快照是在一个后台线程去做的。
默认的配置值为100000，因为做快照会影响性能，所以最好不要让集群中的所有server同时做快照，只要不同时做快照，那就不会影响处理请求时间。基于这个原因，实际的事务次数是接近于实际的配置值的随机数。
注意如果马上要开始做快照的时候发现上一次快照还在执行中，那么就不会开启新的快照，会等待上一次快照结束，再开始新的一次快照。
autopurge.snapRetainCount
这是当在清理数据时需要保留的快照文件和事务日志文件的个数。快照和事务日志文件会被定期的清理，很明显，不能清空所有的快照文件，因为以后就不能恢复数据了。这个配置项最小的值为3，同时也是默认值。
autopurge.purgeInterval
指定了在2个清理数据间相隔的时间，单位为小时，如果设置为0，那么不会启动自动清理，你只能人工的通过调用zkCleanup.sh脚本来清理数据。
fsync.warningthresholdms
如果对磁盘做一次sync耗费的时间超过配置的值的话(单位为毫秒)，会在日志中打印一次警告信息(fsync.warningthresholdms)。
server会在一个update的事务的ack之前做一个sync操作。如果sync这个系统调用花费了过多的时间，会严重的影响系统性能，默认为1000毫秒。
weight.x=n
这个配置项是跟分组配置一起使用的，当组成quorum时会给每一台server分配一个权重(weight)。当投票的时会使用这个值。集群中有时候只需要其中一些server来投票，比如选举leader和atomic broadcast协议。默认的权重为1。如果配置了分组但没有配置权重，那么每台server的权重都为1。
traceFile
设置这个选项的话，会把ZooKeeper的操作记录到一个trace文件中，文件的命名方式为File.year.month.day(requestTraceFile)。
通过这个文件可以追踪ZooKeeper执行的操作的细节。然而，为了打日志，必须序列化每个操作并写到磁盘。这会消耗CPU和磁盘。切记不要把这个日志打到事务日志的磁盘上。打印这个日志会扰动系统，但可以帮助我们重现问题。还有一点，traceFile的Java system property没有zookeeper前缀。