ZooKeeper集群节点数必须为奇数（如3/5/7）以保障容错能力，且autopurge需同时配置autopurge.snapRetainCount和autopurge.purgeInterval才生效；偶数节点容错性不增反耗资源，单配参数则自动清理不运行。
必须用奇数个节点（3/5/7），且 autopurge 两个参数要同时配全，否则自动清理根本不会运行。
为什么 ZooKeeper 集群节点数必须是奇数
ZooKeeper 依赖 ZAB 协议实现数据一致性和 Leader 选举，所有写操作需获得「过半节点」确认才能提交。这意味着：
- 2 节点集群：过半 = 2，挂 1 台就不可写，等同单点
- 3 节点集群：过半 = 2，允许 1 台故障，仍可服务
- 4 节点集群：过半 = 3，允许 1 台故障，但容错能力与 3 节点相同，却多消耗资源
- 5 节点集群：过半 = 3，允许 2 台故障，适合高可用场景
所以生产环境只推荐 3 或 5，不建议用 2、4、6 等偶数——不是不能启，而是失去容错设计意义，还浪费连接开销和磁盘 IO。
zoo.cfg 中必须同时设置的 autopurge 参数
Autopurge 不是“开了一个就生效”的功能，它需要两个配置项严格配合：
-
autopurge.snapRetainCount：最小值为3，表示保留最近多少个snapshot.*文件（及其关联的log.*） -
autopurge.purgeInterval：单位是小时，必须为正整数（如1或24），0表示禁用
只配其中一个，ZooKeeper 启动日志里不会出现 Starting AutoPurge Task，dataDir/version-2/ 下的快照数量也会持续增长。常见错误配置：
autopurge.snapRetainCount=3 # autopurge.purgeInterval=24 ← 这行被注释了 → autopurge 不启动
快照与日志的删除逻辑不是按时间，而是靠 zxid 匹配
Autopurge 删除时并不看文件修改时间或文件名顺序，而是解析每个 snapshot.XXXXXXXX 的 header 获取其最后事务 ID（zxid），再据此确定哪些 log.* 属于该快照范围。因此：
- 手动移动、重命名或复制
snapshot.*或log.*文件会导致 zxid 关联断裂，可能漏删或误删 - 如果某次快照生成后日志写入异常中断，对应
log.*缺失，Autopurge 可能跳过该快照的清理边界判断 -
dataDir和dataLogDir必须分别指定，且目录权限对zookeeper用户可读写，否则连快照都写不进去，更谈不上清理
验证 autopurge 是否真正在工作
改完配置重启后，不能只看配置文件有没有那两行，要实打实验证：
- 查日志：
grep "AutoPurge" zookeeper.out，必须看到INFO级别的Starting AutoPurge Task - 等一个
autopurge.purgeInterval周期后，进dataDir/version-2/目录执行ls snapshot.* | wc -l，结果应 ≈autopurge.snapRetainCount（首次运行可能略多，之后会收敛） - 用
ps aux | grep QuorumPeerMain确认进程是用新zoo.cfg启动的，ZooKeeper 不支持热加载配置
最容易被忽略的是：autopurge 只清理 dataDir 和 dataLogDir 下的快照与日志，完全不管 myid、znode 数据、客户端连接或内存状态——它只是个后台文件管家，不是数据库回收器。
