1. 参数说明

工作节点瞬间压力大，导致和集群通信出现延迟，被踢出节点，瞬间释放的连接立即又连接到另外节点，最终集群挂掉。加了一些延迟配置后，集群稳定。

参数	说明
tickTime=2000	Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime时间就会发送一个心跳。tickTime以毫秒为单位
initLimit=10	集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)
syncLimit=5	集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)
dataDir=/usr/local/zookeeper/data	ZooKeeper存放内存数据结构的snapshot，便于快速恢复
clientPort=2181	客户端连接Zookeeper服务器的端口，Zookeeper会监听这个端口，接受客户端的访问请求
maxClientCnxns=1000	在socket级别限制单个客户端到ZooKeeper集群中单台服务器的并发连接数量，可以通过IP地址来区分不同的客户端，默认是60，设置为0表示不限制并发连接数
minSessionTimeout=30000	服务器允许客户端会话的最小超时时间，以毫秒为单位。默认值是2倍的tickTime
maxSessionTimeout=60000	服务器允许客户端会话的最大超时时间，以毫秒为单位。默认值是20倍的tickTime
autopurge.snapRetainCount=10	当启用自动清理功能后，ZooKeeper将只保留autopurge.snapRetainCount个最近的数据快照(dataDir)和对应的事务日志文件(dataLogDir)，其余的将会删除掉。默认值是3,最小值也是3
autopurge.purgeInterval=1	用于配置触发清理任务的时间间隔，以小时为单位。要启用自动清理，可以将其值设置为一个正整数(比如1)，默认值是0
globalOutstandingLimit=200	客户端提交请求的速度可能比ZooKeeper处理的速度快得多，特别是当客户端的数量非常多的时候。为了防止ZooKeeper因为排队的请求而耗尽内存，ZooKeeper将会对客户端进行限流，即限制系统中未处理的请求数量不超过globalOutstandingLimit设置的值，默认的限制是1000
preAllocSize=131072	单位KB，用于配置ZooKeeper事务日志文件预分配的磁盘空间大小。默认的块大小是64MB。改变块大小的其中一个原因是当数据快照文件生成比较频繁时可以适当减少块大小。比如1000次事务会新产生一个快照(参数为snapCount)，新产生快照后会用新的事务日志文件，假设一个事务信息大小100B，那么事务日志预分配的磁盘空间大小为100kB会比较好
snapCount=300000	ZooKeeper将事务记录到事务日志中。当snapCount个事务被写到一个日志文件后，启动一个快照并创建一个新的事务日志文件。snapCount的默认值是100000
leaderServes=yes	leader是否接受client请求,默认为yes即leader可以接受client的连接，当节点数为>3时，建议关闭。在ZooKeeper中，Leader服务器主要协调事务更新请求。对于事务更新请求吞吐很高而读取请求吞吐很低的情况可以配置Leader不接受客户端连接，这样就可以专注于协调工作
server.1=192.168.1.5:2888:3888	2888 leader\follower传输信息端口，3888选举端口
server.2=192.168.1.6:2888:3888	2888 leader\follower传输信息端口，3888选举端口
server.3=192.168.1.7:2888:3888	2888 leader\follower传输信息端口，3888选举端口

2. Zookeeper优化建议

a. 将ZooKeeper与其他应用分开部署，避免相互影响

对于ZooKeeper来说，如果在运行过程中，需要和其它应用程序来竞争磁盘、CPU、网络、内存资源，那么整体性能将会大打折扣。我们在使用ZooKeeper初期尝试将ZooKeeper与其他应用公用机器，在系统流量上涨后，由于IO及CPU被其他应用使用很大，造成ZooKeeper的Session经常超时甚至应用与ZooKeeper的连接断开。因此，建议ZooKeeper与其他应用分开部署。

b. 将数据文件和事务日志分开存放，提高ZooKeeper性能

我们先分析一下磁盘对ZooKeeper性能的影响。客户端对ZK的更新操作都是永久的，不可回退的，ZK会将每次更新操作以事务日志的形式写入磁盘，写入成功后才会给予客户端响应。明白这点之后，你就会明白磁盘的吞吐性能对于ZK的影响了，磁盘写入速度制约着ZK每个更新操作的响应。因此，我们在选择机型时尽量选择多块硬盘的机器，ZK的事务日志输出是一个顺序写文件的过程，本身性能是很高的，所以尽量保证不要和其它随机写的应用程序共享一块磁盘，尽量避免对磁盘的竞争。

c. 尽量避免内存与磁盘空间的交换，确保设置一个合理的JVM堆大小

如果设置太大，会让内存与磁盘进行交换，这将使ZK的性能大打折扣。例如一个4G内存的机器的，如果你把JVM的堆大小设置为4G或更大，那么会使频繁发生内存与磁盘空间的交换，通常设置成3G就可以了。

3. Zookeeper性能查看

1、Zookeeper服务器当前节点配置信息: echo conf|nc localhost 2181
2、cons：echo cons|nc localhost 2181 输出当前服务器所有客户端连接的详细信息
3、crst:重置所有客户端连接统计信息
4、dump:echo dump|nc localhost 2181，输出当前集群的所有会话消息
5、envi：echo envi|nc localhost 2181，输出服务器运行时的环境信息
6、ruok：echo ruok|nc localhost 2181，输出当前Zookeeper是否正在运行。是，则返回 ‘imok’
7、stat：echo stat|nc localhost 2181，服务器运行时状态信息
8、srvr：和stat功能一致，但不会输出客户端连接情况
9、srst：重置所有服务器统计信息
10、wchs：echo wchs|nc localhost 2181，输出当前服务器管理的Watcher信息
11、wchp：echo wchp|nc localhost 2181，与wchs类似，但以节点路径为单位对Watcher信息进行归组
12、mntr：echo mntr|nc localhost 2181，比stat更为详尽的服务器信息
mntr:列出服务器的健康状态：
zk_version

版本

zk_avg_latency

平均延时

zk_max_latency

最大延时

zk_min_latency

最小延时

zk_packets_received

收包数

zk_packets_sent

发包数

zk_num_alive_connections

连接数

zk_outstanding_requests

堆积请求数

zk_server_state

leader/follower 状态

zk_znode_count

znode数量

zk_watch_count

watch数量

zk_ephemerals_count

临时节点（znode）

zk_approximate_data_size

数据大小

zk_open_file_descriptor_count

打开的文件描述符数量

zk_max_file_descriptor_count

最大文件描述符数量

zk_followers

follower 数量，leader角色才会有这个输出

zk_synced_followers

同步的 follower 数量

shell终端输入：echo mntr| nc localhost 2181

参数解析如下：

zk_server_state 说明：集群中有且只能有一个leader，没有leader，则集群无法正常工作；两个或以上的leader，则视为脑裂，会导致数据不一致问题

zk_followers /zk_synced_followers 说明：如果上述两个值不相等，就表示部分follower异常了需要立即处理，很多低级事故，都是因为单个集群故障了太多的follower未及时处理导致

zk_outstanding_requests 说明：常态下该值应该持续为0，不应该有未处理请求

zk_pending_syncs 说明：常态下该值应该持续为0，不应该有未同步的数据

zk_znode_count 说明：节点数越多，集群的压力越大，性能会随之急剧下降 经验值：不要超过100万 建议：当节点数过多时，需要考虑以机房/地域/业务等维度进行拆分

zk_approximate_data_size 说明：当快照体积过大时，ZK的节点重启后，会因为在initLimit的时间内同步不完整个快照而无法加入集群 经验值：不要超过1GB体积 建议：不要把ZK当做文件存储系统来使用

zk_open_file_descriptor_count/zk_max_file_descriptor_count 说明：当上述两个值相等时，集群无法接收并处理新的请求 建议：修改/etc/security/limits.conf，将线上账号的文件句柄数调整到100万

zk_watch_count 说明：对于watch的数量较多，那么变更后ZK的通知压力也会较大

zk_packets_received/zk_packert_sent 说明：ZK节点接收/发送的packet的数量，每个节点的具体值均不同，通过求和的方式来获取集群的整体值 建议：通过两次命令执行间隔1s来获取差值

zk_num_alive_connections 说明：ZK节点的客户端连接数量，每个节点的具体值均不同，通过求和的方式来获取集群的整体值 建议：通过两次命令执行间隔1s来获取差值

zk_avg_latency/zk_max_latency/zk_min_latency 说明：需要关注平均延时的剧烈变化，业务上对延时有明确要求的，则可以针对具体阈值进行设置

4. 建议

Zookeeper 不落盘配置，对使用dlock分布式锁非常频繁，IO占用很高的情况下可以使用此方案，提升ZK性能，分布式锁单独部署zk，数据不落盘： 在/dev/shm下创建两个目录datadir和logdir，zk的配置文件把datadir和logdir指向对应创建目录，并设置forceSync=no. 这个方案是在zk服务器内存充足时使用，并将zk快照数量控制在5个左右。