redis 7.0 multi-part aof显著提升恢复效率，核心是将恢复从顺序回放巨型日志改为“读manifest定位文件链+并行加载base.aof（rdb快照）+按序应用完好incr-*.aof”，支持跳过损坏增量文件，且manifest必须完整。
Redis 7.0 的 multi-part AOF 能显著提升集群恢复效率，核心在于它把恢复过程从「顺序回放一个巨型日志」变成「定位有效文件链 + 并行加载基础快照 + 按序应用增量」。这不是单纯拆文件，而是重构了恢复的入口、粒度和容错逻辑。
manifest.aof 是恢复的唯一入口，必须保障其完整性
旧版 AOF 恢复依赖扫描整个 appendonly.aof 文件，从头读到尾，遇到损坏就卡住或截断；multi-part AOF 启动时只读 manifest.aof —— 它是一个极小的 JSON 清单文件（通常几百字节），记录了当前有效的 base.aof 和所有已提交的 incr-*.aof 文件名、校验和、生效范围（如起始偏移、命令计数）。只要这个文件没丢、没坏，Redis 就能精准跳过损坏的 incr-*.aof，继续用前序 base + 其他完好 incr 恢复。
常见错误现象：redis-server 启动时报错 Failed to load manifest.aof: invalid format 或直接 abort，说明 manifest 已损坏。此时无法自动恢复，需人工介入。
- 不要手动编辑或备份
manifest.aof—— 它由 Redis 自动维护，写入是原子的 - 确保
appenddirname所在磁盘有足够空间且不被监控脚本误删（比如某些清理脚本会匹配*.aof通配符，可能误删manifest.aof） - 生产环境建议对
manifest.aof做单独定时备份（例如每小时 cp 一次），比备份整个 AOF 目录更轻量、更关键
base.aof 是 RDB 快照，加载速度远超旧式 AOF 回放
base.aof 实质是轻量级 RDB 格式（非文本命令），Redis 加载它走的是 RDB 解析路径：内存映射 + 批量反序列化，速度比逐条解析文本命令快 5–10 倍。一个 2GB 的 base.aof，加载时间通常在秒级；而同等数据量的旧 AOF（含数百万条 *3$3SET...）可能需要分钟级。
使用场景：集群冷启动、节点故障后重建、灾备切换等对恢复时间（RTO）敏感的环节。
- 升级 Redis 7 后若保留旧
appendonly.aof，首次启动仍会先加载它（兼容性行为），导致启动慢、内存瞬时飙升 —— 必须手动执行BGREWRITEAOF触发生成新base.aof+incr-*.aof，再删掉旧文件 -
base.aof默认只存在一个，不会冗余；但它的生成时机受aof-rewrite-incremental-fsync和aof-rewrite-min-size控制，不是每次 incr 写满就滚动生成 - 如果业务写入低频（如每小时才几百条），
base.aof可能长期不更新，此时恢复主要靠manifest+ 最近几个incr-*.aof，总数据量小、加载更快
incr-*.aof 支持跳过损坏文件，恢复不再“一损俱损”
旧版 AOF 里任意一条命令格式错误（如截断、乱码），redis-check-aof --fix 只能从第一个错误位置起全部截断，丢失后续所有数据；multi-part AOF 中每个 incr-*.aof 是独立文件，Redis 在加载时会对每个文件做 CRC 校验，发现损坏就直接跳过该文件，继续加载下一个。
性能影响：跳过一个 incr 文件，只损失该文件覆盖时间段内的写入（默认单个 incr 文件最大 256MB，按写入速率可估算时间窗口），而非整条历史。
- 损坏识别靠日志：启动时若看到
Skipping incr-0000000003.aof due to checksum mismatch，说明机制生效 - 不要依赖
redis-check-aof修复 multi-part AOF —— 它不识别manifest结构，强行修复会破坏清单一致性 - 若频繁出现 incr 文件损坏，优先排查磁盘 I/O 错误、文件系统异常，而非调整 Redis 配置
配置 multi-part AOF 的关键开关与陷阱
multi-part AOF 默认开启，但极易被两个配置项悄悄禁用：一是 aof-use-rdb-preamble yes（退化为 6.x 混合模式），二是 appendonly no（AOF 关闭）。验证是否真正在用，不能只看版本号。
实操建议：
- 检查配置：运行
CONFIG GET aof-use-rdb-preamble，返回值必须是no；同时确认CONFIG GET appendonly为yes - 查看目录：进入
appenddirname（注意不是dir），执行ls -l，应看到base.aof、incr-*.aof、manifest.aof三类文件，**绝不能**还存在appendonly.aof - 重写策略调整：旧版靠
auto-aof-rewrite-percentage触发全量重写；multi-part 下该参数失效，改由后台线程根据aof-rewrite-incremental-fsync和aof-rewrite-min-size控制 incr 合并节奏，无需调高百分比阈值 - 最易踩的坑：升级后未清旧 AOF 文件，或误将
aof-use-rdb-preamble设为yes却以为启用了 multi-part —— 这两种情况都会导致恢复效率毫无提升
真正起效的 multi-part AOF，让恢复从“赌运气”变成“可预期”。但它的可靠性高度依赖 manifest 的完好和磁盘底层的稳定性，这两点往往比调参更重要。
