Raft 日志压缩窗口：Snapshot 太勤和太懒都危险
一、日志不能无限增长
Raft 集群运行久了，日志会不断增长。Snapshot 可以压缩历史日志，减少磁盘占用和新节点追赶成本。但 Snapshot 太勤，会增加 IO 和状态机序列化压力；太懒，日志膨胀、恢复变慢、磁盘风险上升。
日志压缩窗口要根据写入速率、状态机大小、磁盘能力和恢复目标一起定。
二、压缩路径要清楚
flowchart TD A[日志追加] --> B[提交并应用] B --> C[达到压缩阈值] C --> D[生成 Snapshot] D --> E[持久化元数据] E --> F[删除旧日志]只有已经提交并应用到状态机的日志，才可以被 snapshot 覆盖。删除旧日志前，必须确认 snapshot 持久化成功，且元数据能用于恢复。
snapshot_policy: trigger_log_entries: 50000 trigger_log_bytes: 1073741824 keep_trailing_entries: 5000keep_trailing_entries可以减少 follower 轻微落后时直接安装 snapshot 的概率。
三、Snapshot 要避免阻塞前台
struct SnapshotMeta { last_included_index: u64, last_included_term: u64, checksum: String, }生成 snapshot 可能很重，不能长时间阻塞写入路径。常见做法是后台生成一致性视图，完成后原子发布元数据。状态机如果支持增量 snapshot，也可以降低一次性 IO 压力。
还要给 snapshot 文件加 checksum。恢复时先校验完整性，避免用损坏快照启动节点。分布式系统里，坏数据恢复比启动失败更危险。
避免前台阻塞的常见技巧是 Copy-On-Write 快照。在 Rust 实现中，状态机可用Arc包裹内部数据结构，生成 snapshot 时克隆 Arc 获得只读视图，后台线程基于该视图序列化，前台写入继续基于新版本。代价是快照过程中峰值内存翻倍——旧版本和新版本同时存在。对于内存紧张场景，增量快照更合适：仅序列化上次 snapshot 以来变化的 key-range。在 RocksDB 等 LSM 引擎上做 Raft 状态机时，原生 Checkpoint 接口已有 hard link 优化，注意检查点目录的清理时机即可。另有一个易忽略的细节：snapshot 格式必须向前兼容，因为集群中不同版本节点可能互相安装 snapshot，如果新格式被旧版本 follower 解析失败，会阻塞成员变更和日志追赶，建议在 snapshot 头部写入格式版本号。
四、窗口要跟恢复目标绑定
如果目标是新节点 10 分钟内追上集群，就要估算日志回放速度和 snapshot 安装速度。压缩窗口不是拍脑袋的数字。
recovery_objective: max_join_minutes: 10 max_replay_entries: 100000 snapshot_bandwidth_mb_s: 80写入高峰期也要考虑。平时 5 万条日志可能很小，活动期间 5 万条日志可能很大。触发条件最好同时看条数、字节数和时间。
Snapshot 发送也会占网络。给落后 follower 安装快照时，要限速或走后台通道，避免打爆 leader 的前台复制。恢复流量和业务流量抢资源，是很多集群抖动的来源。
最后，压缩要纳入故障演练。正在生成 snapshot 时宕机、snapshot 写到一半断电、删除日志前失败、安装 snapshot 中断，这些路径都要测试。只测正常压缩，不能证明恢复可靠。
Snapshot 任务还要有限速。生成快照会读状态机、写磁盘、占用 CPU，如果和前台写入抢资源，会让整个集群延迟抖动。后台任务应该有 IO 配额，并在前台压力高时主动让路。
snapshot_throttle: max_io_mb_s: 80 pause_when_write_p95_ms: 50 resume_after_cooldown_seconds: 30压缩策略还要记录决策原因。是因为日志条数触发、字节数触发，还是距离上次快照太久触发？这些信息能帮助后续调整窗口，而不是只看到“系统生成了一次快照”。
五、总结
Raft 日志压缩窗口要平衡磁盘、IO、恢复速度、follower 追赶和前台复制压力。
Snapshot 太勤会扰动系统，太懒会拖垮恢复。把窗口和恢复目标绑定，压缩策略才有工程依据。
