multi-part aof文件结构包含base.aof（rdb格式全量快照）、多个incr-*.aof（文本增量日志）和appendonly.aof.manifest（启动时读取的元数据清单），三者共存且相互校验，缺一不可。

multi-part AOF 的文件结构到底长什么样

它不是简单把 appendonly.aof 拆成多个同质小文件，而是明确划分三类角色：base.aof（全量快照）、incr-*.aof（增量命令日志）、appendonly.aof.manifest（元数据清单）。这三者必须共存且相互校验，缺一不可。

常见错误现象：redis-server 启动时报 Failed to load manifest.aof: invalid format 或 no base file found，基本可以断定是 manifest 文件损坏、被手动编辑，或目录里混入了未被清单记录的孤立 .aof 文件。

• base.aof 是 RDB 格式二进制文件，加载走的是内存映射 + 批量反序列化路径，速度比旧式文本 AOF 快 5–10 倍
• incr-*.aof 是纯文本 Redis 协议命令，每个文件只承载一段时间内的增量写入，体积可控（通常几 MB 到几十 MB）
• manifest.aof 是纯文本 JSON 或行格式清单，只在启动时读一次，不参与命令回放；内容包含每类文件名、校验和、生效范围（如起始偏移、命令计数）

aof-use-rdb-preamble no 为什么是启用 multi-part 的硬性开关

这个配置项直接决定 Redis 走哪条持久化路径：如果 CONFIG GET aof-use-rdb-preamble 返回 yes，Redis 会退回到 6.x 的混合模式（RDB 头 + AOF 尾），仍用单文件 + aof_rewrite_buf；只有返回 no，才真正启用 multi-part，生成 base.aof、incr-*.aof 和 manifest。

容易踩的坑：

• 运维脚本误删：某些清理脚本用 *.aof 通配符匹配，可能顺手把 manifest.aof 删掉，导致启动失败
• appenddirname 配置缺失或与 dir 混用：multi-part 要求 AOF 文件必须放在独立目录（由 appenddirname 指定），否则文件混放易被误操作
• 手动备份不完整：只备份部分 incr-*.aof 或漏掉 manifest.aof，恢复时无法重建有效链

重写过程不再 fork + rewrite_buf，那新机制怎么保证数据一致性

旧版 AOF 重写卡顿的核心是 fork 子进程复制页表 + 主进程狂塞 aof_rewrite_buf 缓冲区，高写入下缓冲区无上限膨胀，极易 OOM 或阻塞主线程。multi-part 彻底移除了 aof_rewrite_buf，改用“滚动生成”策略：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• base.aof 只在真正需要全量快照时（比如首次启用、上一个 base 过期、或触发 CONFIG REWRITE）由子进程生成，频率大幅降低
• incr-*.aof 由主线程直接写入磁盘，不经过大块内存缓冲，每个文件写满或超时即自动关闭，新建下一个
• 重写逻辑退化为“切换文件描述符”，主线程几乎无额外开销；实测 10GB 数据集下，重写期间 RSS 增长稳定在 40MB 左右

这意味着你看到的日志里不再有 Background AOF rewrite started 这类旧式提示，取而代之的是 Creating new incr AOF file 或 Starting automatic rewriting of AOF on base.aof size。

appendfsync everysec 在 multi-part 下同步谁、怎么同步

策略本身没变，但作用对象变了：现在 appendfsync everysec 同步的是**最新那个 incr-*.aof 文件**，而不是整个日志链。每个 incr 文件写入后立即 fdatasync，耗时稳定在毫秒级，不再有“最后一秒攒一堆命令等同步”的 I/O 尖峰。

性能影响很实在：

• 延迟波动下降 60% 以上：因为 fsync 分散到多个小文件，主线程调度更平滑
• 容错能力增强：某个 incr-*.aof 文件损坏，manifest 可跳过它继续加载前序 base + 其他完好 incr，恢复链不中断
• 但注意：everysec 仍不能保证 100% 不丢数据——如果刚好在 fsync 前宕机，最多丢失该 incr 文件最后 1 秒的命令

真正落地时最容易被忽略的，不是配置是否打开，而是 manifest.aof 的完整性保障和 appenddirname 目录的独立性管理。这两个点一旦出问题，multi-part 的所有优势都会归零。