Multi-part AOF通过将增量日志拆分为多个小文件（incr-*.aof），每个写满或超时后立即fdatasync，单次耗时稳定在1–3ms，避免旧版everysec模式下重写时aof_rewrite_buf导致的I/O尖峰。
Multi-part AOF 怎么分散 fsync 压力
旧版 AOF 在 appendfsync everysec 模式下，所有增量命令先攒在 aof_buf 里，每秒统一刷一次整个文件 —— 一旦重写触发，aof_rewrite_buf 还要额外追加，I/O 尖峰不可避免。Multi-part AOF 把这个“集中爆发”拆成了“细水长流”：每个 incr-*.aof 文件写满或超时后立即 fdatasync，数据量小、耗时稳、失败影响面窄。
关键点在于：appendfsync 不再作用于一个巨型文件，而是只针对当前正在写的那个 incr-*.aof。实测单次 fdatasync 耗时稳定在 1–3ms，不再出现几十毫秒的毛刺。
- 不依赖
aof_rewrite_buf，主线程无大块内存拷贝和同步等待 - 每个
incr-*.aof文件大小默认上限为 256MB（可调），天然限流 - 即使某个
incr-*.aof因磁盘卡顿刷慢，不影响其他文件的调度
appenddirname 配置错误会导致 IO 误伤
Redis 7.0 要求把 multi-part AOF 文件（base.aof、incr-*.aof、manifest.aof）单独放在 appenddirname 目录下，且该目录必须与 dir 分离。如果配成一样，或留空（回退到 dir），就会混入 dump.rdb 等其他文件 —— 运维脚本用 find /var/lib/redis -name "*.aof" -delete 一类通配清理时，可能顺手干掉 manifest.aof 或正在写的 incr-*.aof，直接导致启动失败或数据丢失。
更隐蔽的问题是：若 appenddirname 所在磁盘空间不足，Redis 会静默降级为单文件模式（只写 appendonly.aof），但日志未必报错，你得靠 CONFIG GET aof-use-rdb-preamble 和文件列表交叉验证。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
appenddirname必须显式配置，不能省略 - 建议用独立挂载点，避免和系统日志、RDB 共享磁盘
- 监控项应包含
appenddirname的可用空间，而非仅看dir
manifest.aof 是 IO 调度的总开关，不是可选附件
manifest.aof 看似只是个几百字节的 JSON 清单，但它决定了 Redis 启动时加载哪些文件、跳过哪些损坏的 incr-*.aof、从哪个 offset 继续应用。它本身也参与 I/O 路径：每次新生成 incr-*.aof 或完成 base.aof，Redis 都要原子重写 manifest.aof。如果这块磁盘延迟高或频繁丢写，manifest 可能损坏，进而让整个恢复链失效。
常见误操作是把 manifest.aof 加进 logrotate 或定时 rsync 备份 —— 它不是静态文件，而是一个实时维护的状态指针。备份必须用 cp 命令在 SAVE 或 BGREWRITEAOF 后做快照，且需校验 sha256sum。
- 不要对
manifest.aof做 inotify 监控或自动同步 - 生产环境建议每小时
cp appendonlydir/manifest.aof manifest.aof.$(date +%s) - 若发现
Failed to load manifest.aof: invalid format，说明已损坏，无法自动恢复
incr-*.aof 文件数量过多会拖慢启动加载
虽然 multi-part AOF 支持跳过损坏文件，但启动时仍需按顺序读取 manifest.aof 列出的所有 incr-*.aof，逐个 open() + stat() + 校验 checksum。如果长期未触发 base 重写，incr-*.aof 积累到几百个，光是打开文件的系统调用开销就可能达数百毫秒，尤其在机械盘或高延迟云盘上。
这不是设计缺陷，而是权衡：用少量文件合并代价换来了重写期间的低抖动。所以需要主动管理 —— 通过 aof-rewrite-incremental-fsync yes（默认开启）让后台线程逐步合并旧 incr，或定期触发 CONFIG SET auto-aof-rewrite-percentage 100 强制生成新 base。
- 默认每 30 分钟检查一次是否需要滚动生成新 base
- 可通过
INFO persistence中的aof_current_incr_files和aof_base_last_rewrite_time_sec监控积压程度 - 不建议手动
rm incr-*.aof，必须走BGREWRITEAOF或等自动合并
appenddirname 是否隔离、manifest.aof 是否被当作普通文件对待、以及 incr 文件是否长期无人收敛。 
