redis 7 的 multi-part aof 是将写操作分散到多个小文件（如.base.rdb和.incr.aof）的机制，本质区别在于重写不再依赖全量内存快照和fork子进程，而是通过异步追加与增量合并实现，内存占用稳定在几十mb。
Redis 7 的 Multi-Part AOF 是什么，和旧版 rewrite 有什么本质区别
Redis 7 不再用单一大文件做 AOF rewrite，而是默认启用 multi-part AOF（多段 AOF），把写操作分散到多个小文件中。旧版（6.x 及之前）在 bgrewriteaof 时需加载全量数据构建新 AOF，内存峰值≈当前 dataset 大小；而 Multi-Part 模式下，重写过程不依赖全量内存快照，改由 aof-write-thread 异步追加 + aof-rewrite-diff 增量合并完成，内存占用稳定在几十 MB 级别（仅用于缓冲差异日志）。
关键变化在于：它把「重写」从“重建整个历史”变成“滚动合并最近变更”，不再需要 fork() 出一个与父进程等大的子进程。
如何确认你的 Redis 7 正在使用 Multi-Part AOF
启动后检查日志或配置即可判断是否生效。默认开启，但需满足两个前提：
-
aof-enabled yes（AOF 必须启用） -
aof-use-rdb-preamble no（必须禁用 RDB-AOF 混合格式；若为yes，Multi-Part 会自动退化为传统单文件模式）
运行中可执行：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
CONFIG GET aof-use-rdb-preamble确认值为
no；再看 dir 目录下是否存在类似 appendonly.aof.1.base.rdb、appendonly.aof.2.incr.aof 这类命名的文件——有则说明 Multi-Part 已激活。
升级到 Redis 7 后，老 AOF 文件怎么处理
直接升级不会自动转换。原 appendonly.aof 会被保留，但 Redis 7 启动时检测到该文件且未启用 aof-use-rdb-preamble，会把它作为初始 base 文件，然后新建 .incr.aof 分段追加。此时你有两个选择：
- 手动触发一次
REWRITEAOF：Redis 会生成新的.base.rdb+.incr.aof，之后就完全走 Multi-Part 流程 - 不做干预，让旧 AOF 继续被读取并逐步归档——但要注意：只要旧文件存在，重启时仍会先加载它，导致启动慢、内存瞬时升高
建议上线前先执行 REWRITEAOF，再删掉旧 appendonly.aof，避免冷启动风险。
Multi-Part AOF 的磁盘与恢复行为需要注意什么
它不是“无代价”的优化。每个 .incr.aof 文件都对应一段增量操作，Redis 启动时需按序加载所有有效分段。这意味着：
- 分段越多，启动耗时越长（尤其当有数百个
.incr.aof未合并时） -
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size依然生效，但触发的是「合并部分增量段 into 新 base」，不是全量重写 - 运维上要留意
aof-load-truncated日志——如果某个.incr.aof被截断（如磁盘满后写入中断），Redis 默认跳过该段，可能导致数据丢失（可通过aof-ignore-truncated-incr控制）
最易忽略的一点：备份脚本若还硬编码 appendonly.aof 路径，会漏掉所有 .incr.aof 和 .base.rdb，恢复时只剩空库。
