zookeeper默认配置文件为zoo.cfg，如果我们要使用zoo1.cfg作为配置文件时使用命令：zkServer.sh start zoo1.cfg
接下来我们将说明zookeeper中较为重要的一些配置，其中主要内容根据《从 Paxos 到 ZooKeeper 分布式一致性原理与实践》和《ZooKeeper-分布式过程协同技术》得来：
1，zoo.cfg默认带的参数：
| 参数名 | 说明 | |
|---|---|---|
| tickTime | 用于配置 ZooKeeper 中最小时间单位的长度，很多运行时的时间间隔都是使用 tickTime 的倍数来表示的。例如，ZooKeeper 中会话的最小超时时间默认是 2*tickTime；单位为毫秒，默认配置2000。 | |
| 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 集群的网络环境质量较低（例如网络延时较大或丢包严重），那么可以适当调大这个参数。 | |
| dataDir | 用于配置 ZooKeeper 服务器存储快照文件的目录。默认情况下，如果没有配置参数 dataLogDir，那么事务日志也会存储在这个目录中。考虑到事务日志的写性能直接影响 ZooKeeper 整体的服务能力，因此建议同时通过参数 dataLogDir 来配置 ZooKeeper 事务日志的存储目录。如果某个服务器为集群中的一台，id文件也保存在该目录下。该参数无默认值，必须配置。 | |
| clientPort | 用于配置当前服务器对外的服务端口，客户端会通过该端口和 ZooKeeper 服务器创建连接，一般设置为2181。每台 ZooKeeper 都可以配置任意可用的端口，同时集群中的所有服务器不需要保持 clientPort 端口一致。该参数无默认值，必须配置。 |
2，其他较重要配置
| 参数名 | 说明 |
|---|---|
| dataLogDir | 该参数有默认值: dataDir，可以不配置，不支持系统属性方式配置。参数 dataLogDir 用于配置 ZooKeeper 服务器存储事务日志文件的目录。默认情况下，ZooKeeper 会将事务日志文件和快照数据存储在同一目录中，应该尽量将这两者的牧区区分开来。另外，如果条件允许，可以将事务日志的存储位置配置在一个单独的磁盘上。事务日志记录对于磁盘的性能要求非常高，为了保证数据的一致性，ZooKeeper 在返回客户端事务请求相应之前，必须将本次请求对应的事务日志写入到磁盘中。因此，事务日志写入的性能直接决定了 ZooKeeper 在处理事务请求时的吞吐。针对同一块磁盘的其他并发读写操作（例如 ZooKeeper 运行时日志输出和操作系统自身的读写等），尤其是数据快照操作，会极大地影响事务日志的写性能。因此尽量给事务日志的输出配置一个单独的磁盘或挂载点，将极大地提升 ZooKeeper 的整体性能。 |
| snapCount | 指定每次快照之间的事务数（zookeeper.snapCount）。当Zookeeper服务器重启后需要恢复其状态，恢复时两大时间因素分别是为恢复状态而读取快照的时间以及快照启动后所发生的事务的执行时间。执行快照可以减少读入快照文件后需要应用的事务数量，但是进行快照时也会影响服务器性能，即便是通过后台线程的方式进行写入操作。snapCount的默认值为100000，因为进行快照时会影响性能，所以集群中所有服务器最好不要在同一时间进行快照操作，只要仲裁服务器不会一同进行快照，处理时间就不会受影响，因此每次快照中实际的事务数为一个接近snapCount值的随机数。注意，如果snapCount数已经达到，但前一个快照正在进行中，新的快照将不会开始，服务器也将继续等到下一个snapCount数量的事务后再开启一个新的快照。 |
| preAllocSize | 用于设置预分配的事务日志文件（zookeeper.preAllocSize）的大小值，以KB为单位。当写入事务日志文件时，服务端每次会分配preAllocSize值的KB的存储大小，通过这种方式可以分摊文件系统将磁盘分配存储空间和更新元数据的开销，更重要的是，该方式也减少了文件寻址操作的次数。默认情况下preAllocSize的值为64MB，缩小该值的一个原因是事务日志永远不会达到这么大，因为每次快照后都会重新启动一个新的事务日志，如果每次快照之间的日志数量很小，而且每个事务本身也很小，64MB的默认值显然就太大了。例如，如果我们每1000个事务进行一次快照，每个事务的平均大小为100字节，那么100KB的preAllocSize值则更加合适。默认的preAllocSize值的设置适用于默认的snapCount值和平均事务超过512字节的情况。 |
| minSessionTimeout | 最小会话超时时间，单位为毫秒。当客户端建立一个连接后就会请求一个明确的超时值，而客户端实际获得的超时值不会低于minSessionTimeout的值。ZooKeeper开发人员很想立刻且准确地检测出客户端故障发生的情况，遗憾的是，系统不可能实时处理这种情况，而是通过心跳和超时来处理。超时取决于ZooKeeper客户端与服务器之间的响应能力，更重要的是两者之间的网络延时和可靠性。超时时间允许的最小值为客户端与服务器之间网络的环回时间，但偶尔还是可能发生丢包现象，当这种情况发生时，因为重传超时导致接收响应时间的增加，并会导致接收重发包的延时。minSessionTimeout的默认值为tickTime值的两倍。配置该参数值过低可能会导致错误的客户端故障检测，配置该参数值过高会延迟客户端故障的检测时间 。 |
| maxSessionTimeout | 会话的最大超时时间值，单位为毫秒。当客户端建立一个连接后就会请求一个明确的超时值，而客户端实际获得的超时值不会高于maxSessionTimeout的值。虽然该参数并不会影响系统的性能，但却可以限制一个客户端消耗系统资源的时间，默认情况下maxSessionTimeout的时间为tickTime的20倍。 |
| maxClientCnxns | 允许每个IP地址的并发socket连接的最大数量。Zookeeper通过流量控制和限制值来避免过载情况的发生。一个连接的建立所使用的资源远远高于正常操作请求所使用的资源。我们曾看到过某些错误的客户端每秒创建很多ZooKeeper连接，最后导致拒绝服务（DoS），为了解决这个问题，我们添加了这个选项，通过设置该值，可以在某个IP地址已经有maxClientCnxns个连接时拒绝该IP地址新的连接。该选项的默认值为60个并发连接。注意，每个服务器维护着这个连接的数量，如果我们有一个5个服务器的集群，并且使用默认的并发连接数60，一个欺诈性的客户端会随机连接到这5个不同的服务器，正常情况下，该客户端几乎可以从单个IP地址上建立300个连接，之后才会触发某个服务器的限制。 |
| globalOutstandingLimit | ZooKeeper中待处理请求的最大值（zookeeper.globalOutstandingLimit）。ZooKeeper客户端提交请求比ZooKeeper服务端处理请求要快很多，服务端将会对接收到的请求队列化，最终（也许几秒之内）可能导致服务端的内存溢出。为了防止发生这个问题，ZooKeeper服务端中如果待处理请求达到globalOutstandingLimit值就会限制客户端的请求。但是globalOutstandingLimit值并不是硬限制，因为每个客户端至少有一个待处理请求，否则会导致客户端超时，因此，当达到globalOutstandingLimit值后，服务端还会继续接收客户端连接中的请求，条件是这个客户端在服务器中没有任何待处理的请求。为了确定某个服务器的全局限制值，我们只是简单地将该参数值除以服务器的数量，目前还没有更智能的方式去实现全局待处理操作数量的计算，并强制采用该参数所指定的限制值，因此，该限制值为待处理请求的上限值，事实上，服务器之间完美的负载均衡解决方案还无法实现，所以某些服务器运行得稍缓慢一点，或者处于更高的负载中，即使最终没有达到全局限制值也可能被限制住吞吐量。该参数的默认值为1000个请求，你可能并不会修改该参数值，但如果你有很多客户端发送大数据包请求可能就需要降低这个参数值，但我们在实践中还未遇到需要修改这个参数的情况。 |
| clientPortAddress | 限制客户端连接到指定的接收信息的地址上。默认情况下，一个ZooKeeper服务器会监听在所有的网络接口地址上等待客户端的连接。有些服务器配置了多个网络接口，其中一个网络接口用于内网通信，另一个网络接口用于公网通信，如果你并不希望服务器在公网接口接受客户端的连接，只需要设置clientPortAddress选项为内网接口的地址。 |
| leaderServes | 配置值为“yes”或“no”标志，指示群首服务器是否为客户端提供服务（zookeeper.leaderServes）。担任群首的ZooKeeper服务器需要做很多工作，它需要与所有追随者进行通信并会执行所有的变更操作，也就意味着群首的负载会比追随者的负载高，如果群首过载，整个系统可能都会受到影响。该标志位如果设置为“no”就可以使群首除去服务客户端连接的负担，使群首将所有资源用于处理追随者发送给它的变更操作请求，这样可以提高系统状态变更操作的吞吐能力。换句话说，如果群首不处理任何与其直连的客户端连接，追随者就会有更多的客户端，因为连接到群首的客户端将会分散到追随者上，尤其注意在集群中服务器数量比较少的时候。默认情况下，leaderServes的值为“yes”。 |
| server.x=[hostname]：n：n[：observer] | 服务器x的配置参数。ZooKeeper服务器需要知道它们如何通信，配置文件中该形式的配置项就指定了服务器x的配置信息，其中x为服务器的ID值（一个整数）。当一个服务器启动后，就会读取data目录下myid文件中的值，之后服务器就会使用这个值作为查找server.x项，通过该项中的数据配置服务器自己。如果需要连接到另一个服务器y，就会使用server.y项的配置信息来与这个服务器进行通信。其中hostname为服务器在网络n中的名称，同时后面跟了两个TCP的端口号，第一个端口用于事务的发送，第二个端口用于群首选举，典型的端口号配置为2888：3888。如果最后一个字段标记了observer属性，服务器就会进入观察者模式。注意，所有的服务器使用相同的server.x配置信息，这一点非常重要，否则的话，因服务器之间可能无法正确建立连接而导致整个集群无法正常工作。 |
| cnxTimeout | 在群首选举打开一个新的连接的超时值（zookeeper.cnxTimeout）。ZooKeeper服务器在进行群首选举时互相之间会建立连接，该选项值确定了一个服务器在进行重试前会等待连接成功建立的时间为多久。默认的超时时间为5秒，该值足够大，也许你并不需要修改。 |
| autopurge.snapRetainCount | 当进行清理数据操作时，需要保留在快照数量和对应的事务日志文件数量。ZooKeeper将会定期对快照和事务日志进行垃圾回收操作，autopurge.snapRetainCount值指定了垃圾回收时需要保留的快照数，显然，并不是所有的快照都可以被删除，因为那样就不可能进行服务器的恢复操作。autopurge.snapRetainCount的最小值为3，也是默认值的大小。 |
| autopurge.purgeInterval | 对快照和日志进行垃圾回收（清理）操作的时间间隔的小时数。如果设置为一个非0的数字，autopurge.purgeInterval指定了垃圾回收周期的时间间隔，如果设置为0，默认情况下，垃圾回收不会自动执行，而需要通过ZooKeeper发行包中的zkCleanup.sh脚本手动运行。 |
| fsync.warningthresholdms | 触发警告的存储同步时间阀值（fsync.warningthresholdms），以毫秒为单位。ZooKeeper服务器在应答变化消息前会同步变化情况到存储中。如果同步系统调用消耗了太长时间，系统性能就会受到严重影响，服务器会跟踪同步调用的持续时间，如果超过fsync.warningthresholdms只就会产生一个警告消息。默认情况下，该值为1000毫秒。 |
| weight.x=n | 该选项常常以一组参数进行配置，该选项指定组成一个仲裁机构的某个服务器的权重为n，其权重n值指示了该服务器在进行投票时的权重值。在ZooKeeper中一些部件需要投票值，比如群首选举中和原子广播协议中。默认情况下，一个服务器的权重值为1，如果定义的一组服务器没有指定权重，所有服务器的权重值将默认分配为1。 |
| traceFile | 持续跟踪ZooKeeper的操作，并将操作记录到跟踪日志中，跟踪日志的文件名为traceFile.year.month.day。除非设置了该选项（requestTraceFile），否则跟踪功能将不会启用。该选项用来提供ZooKeeper所进行的操作的详细视图。不过，要想记录这些日志，ZooKeeper服务器必须序列化操作，并将操作写入磁盘，这将争用CPU和磁盘的时间。如果你使用了该选项，请确保不要将跟踪文件放到日志文件的存储设备中。我们还需要知道，跟踪选项还可能影响系统运行，甚至可能会很难重现跟踪选项关闭时发生的问题。另外还有个有趣的问题，traceFile选项的Java系统属性配置中不含有zookeeper前缀，而且系统属性的名称也与配置选项名称不同，这一点请小心。 |