multi-part AOF通过分离BASE（轻量RDB快照）与INCR（仅追加命令）文件，避免重写时全量dump内存，降低fork阻塞；损坏单个INCR可跳过恢复，提升可靠性；manifest文件为恢复入口，需保障其完整性。
multi-part AOF为什么能降低重写阻塞
旧AOF重写（AOFRW）必须 fork 子进程，全量扫描内存数据生成新文件；期间主进程产生的增量命令全靠 aof_rewrite_buf 缓存，一旦写入压力大，缓冲区堆积会导致重写时间不可控，甚至拖垮主线程响应。multi-part AOF 把“全量快照”和“增量日志”彻底拆开，BASE 文件本质是轻量级 RDB 快照，INCR 文件只追加命令——重写时只需滚动生成新的 INCR，不再需要全量 dump 内存。
multi-part AOF修复和恢复更可靠
传统单文件 AOF 一损俱损：redis-check-aof --fix 只能从第一个错误命令起截断后续全部内容，数据丢失风险高。multi-part AOF 的 manifest 清单文件明确记录每个 BASE 和 INCR 文件的生效范围与依赖顺序；损坏单个 INCR 文件时，Redis 可跳过它、用前序 BASE + 其他有效 INCR 恢复，而不是整条链路失效。
- BASE 文件最多一个，天然避免冗余快照
- INCR 文件可按时间或大小自动轮转，便于归档与清理
-
appenddirname配置项独立于dir，防止 AOF 文件混入 RDB 目录造成误删
multi-part AOF让 appendfsync everysec 更敢用
旧版 AOF 在 everysec 模式下，重写过程仍可能因 aof_rewrite_buf 同步延迟引发抖动；multi-part AOF 将 fsync 压力分散到多个小文件，INCR 文件写入后立即 fsync 成本更低，实测重写期间 P99 延迟波动下降 60% 以上。你不用再为了稳定性退回到 no 策略而承担丢数据风险。
真正容易被忽略的是 manifest 文件的完整性——它不参与 fsync，但却是整个 MP-AOF 恢复的入口点。生产环境务必确保 appenddirname 所在磁盘有足够空间且不被监控脚本误删 manifest。
