AOF 追加日志如果一直写下去，文件会越来越大。一个 key 被 INCR 一万次，最终状态也许只是一个数字，但日志里会留下这一万条历史命令。
AOF 重写的目标，就是用当前数据状态生成更短的新日志。难点在于：重写发生时 Redis 还在接收新写入，这些增量必须被安全接到新文件后面。
先把机制边界说清楚
这一篇讨论 AOF 重写和恢复边界，不重复 RDB/AOF 基础。重点是：持久化配置存在，不等于恢复方案可靠。
整体路径
上面这张图先把主线铺开：子进程生成新基线，父进程收集重写期间增量。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- 后台重写会基于当前数据生成更紧凑的新 AOF。
- 重写期间父进程继续处理写命令，并把增量写入缓冲。
- 现代 Redis 的 multi-part AOF 使用 base、incremental 和 manifest 组织文件。
- 混合持久化可以用 RDB 作为基线，再接 AOF 增量，提高恢复速度。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
重写降低恢复成本，但会带来 fork、磁盘写入和额外缓冲。恢复更快，不代表数据窗口自动变小。
典型问题：用机制化例子排查
- 定期做恢复演练，验证启动耗时、数据窗口和文件完整性。
- 监控 rewrite 期间内存、磁盘吞吐和 AOF 增量大小。
- 磁盘容量要覆盖旧文件、新文件和增量同时存在的峰值。
- 不要在写入高峰手动触发大实例 rewrite。
收束：一句判断
持久化真正可靠的标志，不是文件存在，而是你恢复过。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
