Go 实现 Raft 时的日志压缩与快照传输细节
为什么会“越跑越慢” Raft 日志长期不压缩会拖慢重放与追赶；但压缩过于激进又会让慢 follower 频繁走全量快照，网络和磁盘双杀。 压缩策略建议 用“日志条目数 + 磁盘占用”双阈值触发快照。 快照频率按写入速率自适应，而不是固定分钟数。 仅在 commit index 安全推进后截断日志。 安装快照时的工程点 分块传输并带 offset 校验。 最后一块再原子切换状态机数据目录。 快照应用期间限制客户端写入峰值。 Go 侧接口设计 type SnapshotStore interface { Create(meta SnapshotMeta) (io.WriteCloser, error) Open(id string) (io.ReadCloser, SnapshotMeta, error) List(limit int) ([]SnapshotMeta, error) } 常见故障 截断日志早于快照持久化完成，导致节点重启后状态缺口。 快照元数据未纳入 WAL，断电恢复后索引错位。 对慢 follower 缺少限流，拖累 leader。 小结 Raft 的可用性不只来自选主，更来自“日志、快照、复制窗口”三者的节奏匹配。压缩策略设计得当，集群才能长期平稳运行。