Zookeeper 架构和数据模型该怎么设计才稳？

Zookeeper 要稳，先别把它当数据库用，而要当成“小而关键的协调层”。生产集群通常选 3 或 5 个投票节点：3 节点能容忍 1 台故障，5 节点能容忍 2 台故障；节点数不是越多越好，写入要多数派确认，7 台以上会增加选举和同步成本。部署时尽量跨机架或可用区，但不要把网络延迟拉得太大。

追问

为什么生产集群常用 3 或 5 个节点？

Zookeeper 依赖多数派，4 个节点仍然只能容忍 1 台故障，因为多数派需要 3 票。偶数节点增加机器和同步成本，却不提升容错收益。

dataDir 和 dataLogDir 为什么建议分开？

事务日志是写请求关键路径，磁盘抖动会直接放大写延迟。快照文件更偏后台持久化，和日志分盘更稳。

Zookeeper 适合存业务大数据吗？

不适合，它适合配置、状态、锁节点、服务实例这类小数据。大对象会增加网络复制、快照体积和恢复时间。

Watcher 最容易踩什么坑？

原生 Watcher 触发一次就失效，收到事件后要重新注册。回调里不要做重活，应投递异步任务。

分布式锁一定要自己实现吗？

不建议，Curator 的 InterProcessMutex 已处理大量边界。业务侧更应该关注超时时间、finally 释放锁和锁粒度。

写段配置

properties
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data/zookeeper/data
dataLogDir=/data/zookeeper/logs
autopurge.purgeInterval=1