Redis 7.0 multi-part AOF是将AOF重构为base.aof（全量RDB快照）+多个incr-*.aof（增量命令）+manifest.aof（校验清单）的三部分结构，通过分离快照与增量、消除aof_rewrite_buf、分散fsync至单个incr文件，显著降低重写内存开销、避免OOM，并提升恢复可靠性与速度。
Redis 7.0 multi-part AOF 是什么，为什么能减小开销
它不是简单地把 appendonly.aof 拆成几个小文件，而是重构了 AOF 的结构：一个 base.aof（全量快照） + 多个 incr-*.aof（增量命令） + 一个 appendonly.aof.manifest（清单文件）。重写时不再需要把所有历史命令重放一遍，而是只重写当前内存状态到新的 base.aof，再从上次 base 起始点开始记录新命令到新的 incr-*.aof。这直接规避了老版本中 aof_rewrite_buf 缓冲区暴涨、甚至 OOM 的风险。
如何确认 multi-part AOF 已生效
必须同时满足两个条件，否则会退化回旧模式：
-
appendonly yes已启用 -
aof-use-rdb-preamble no（注意是no；若为yes则启用的是 6.x 的 RDB+AOF 混合模式，不走 multi-part）
验证方式：
- 执行
CONFIG GET aof-use-rdb-preamble，返回值必须是"no" - 检查 AOF 目录（由
appenddirname配置指定），应看到类似base.aof、incr-0000000001.aof、appendonly.aof.manifest的文件，而不是单个appendonly.aof - 日志中出现
Starting automatic rewriting of AOF on base.aof size或Creating new incr AOF file
appendfsync 在 multi-part 下的行为变化
策略没变，但作用对象变了：现在 appendfsync everysec 只对最新那个 incr-*.aof 文件做 fsync，而不是整个日志链。这意味着：
- 每次
fsync更轻量——只刷一个小文件，延迟显著降低 - 故障隔离性增强——某个
incr-*.aof损坏，只需丢弃它并重建后续部分，base.aof和已确认的前序增量不受影响 -
always模式下延迟也比老版本低得多，因为不涉及大缓冲区同步
配置与路径注意事项
Redis 7.0 引入了新配置项，容易被忽略：
-
appenddirname必须显式设置（如/var/lib/redis/appendonlydir），否则 multi-part 无法正常创建子目录结构 -
appendfilename仅作为基础前缀使用（默认"appendonly.aof"），实际生成的文件名由 Redis 自动拼接，例如appendonly.aof.1.base.rdb、appendonly.aof.1.incr.aof - 清单文件
appendonly.aof.manifest不可手动修改或删除，否则恢复时会因依赖关系错乱而失败
最易被忽略的一点：multi-part AOF 的恢复速度提升（实测约 40%）高度依赖 manifest 文件的完整性——它不是辅助文件，而是恢复流程的调度中枢。一旦损坏，Redis 启动时可能静默跳过部分增量文件，导致数据丢失而不报错。
