Zookeeper 性能怎么优化？哪些参数最容易踩坑？

Zookeeper 性能优化先分清读多、写多还是连接多。读多可以加 Observer 或让客户端分散到 Follower；写多瓶颈通常在 Leader、事务日志 fsync 和过半确认；连接多、Watcher 多、znode 大，会把内存和网络打满。有效优化不是把参数调大，而是减少无意义写入、控制节点大小、把事务日志放到稳定低延迟磁盘。

追问

加节点一定能提升性能吗？

不一定。Follower 或 Observer 能分担读请求，但写请求仍要 Leader 发起并等待过半确认，投票节点越多，写入链路可能越长。

dataDir 和 dataLogDir 为什么分开？

事务日志每次写入都很敏感，最好放低延迟 SSD 或独立盘；快照体积大但频率低，可以放普通数据盘。

Watcher 多会带来什么问题？

Watcher 会占服务端内存，事件触发时还会产生通知风暴。客户端重连后无脑重复注册，会导致 watch_count 持续上涨。

单个 znode 为什么不建议放大数据？

Zookeeper 是协调元数据系统，不是文件存储。大节点会放大网络传输、序列化、快照和事务日志成本。

性能压测看哪些边界？

至少分读密集、写密集、混合读写、重连风暴和 Watcher 触发场景。每次只改一个参数，记录 P95/P99、磁盘 await、GC pause。

写段配置

properties
tickTime=2000
initLimit=10
syncLimit=5
maxClientCnxns=100
dataLogDir=/data/zookeeper/txnlog
autopurge.purgeInterval=1