redis 7.0 的 multi-part aof 是将 aof 拆分为 base.aof（全量快照）和多个 incr-*.aof（增量日志），以提升重写、加载与同步的可控性与效率。
Redis 7.0 的 multi-part AOF 是什么，为什么需要它
Redis 7.0 引入的 multi-part AOF 不是简单地把一个大文件拆成多个小文件，而是将 AOF 持久化过程解耦为「基础快照 + 增量日志」两部分：一个 base.aof（记录当前全量数据的紧凑快照），加若干个 incr-*.aof（按时间顺序追加的增量命令）。这种结构让重写、加载、同步都更可控。
老版本（aof_rewrite_buf，一旦写入压力大，这个缓冲区可能暴涨，甚至触发 OOM。而 multi-part AOF 把增量命令直接落盘为独立文件，不再依赖大块内存缓冲，从根本上缓解了重写期间的内存压力。
如何启用和验证 multi-part AOF 是否生效
它默认开启，但前提是满足两个条件：AOF 已启用（appendonly yes），且未手动关闭该特性（aof-use-rdb-preamble no 是旧式混合模式，会禁用 multi-part）。
- 检查配置：
config get aof-use-rdb-preamble返回no才表示走纯 multi-part 流程；返回yes则退回到 6.x 的 RDB+AOF 混合模式 - 查看 AOF 目录：
ls -l /var/lib/redis/应能看到类似base.aof、incr-0000000001.aof、incr-0000000002.aof的文件，而非单一的appendonly.aof - 观察日志：
tail -f /var/log/redis/redis-server.log中出现Starting automatic rewriting of AOF on base.aof size或Creating new incr AOF file即为正常工作流
appendfsync 在 multi-part 下的行为变化
策略本身没变，但作用对象变了：现在 appendfsync everysec 同步的是最新那个 incr-*.aof 文件，而不是整个日志链。这意味着 fsync 更轻量、更频繁，也更安全——即使某个增量文件损坏，只需丢弃它并重建后续部分，不影响 base.aof 和已确认的前序增量。
要注意的是，always 模式下每次写仍会触发 fsync，但因只作用于当前增量文件，延迟比老版本低得多；而 no 模式下，OS 缓冲策略依然适用，只是风险被限制在单个增量文件内。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实际部署中，除非对数据零丢失有极端要求，否则 everysec 仍是推荐值——它在 Redis 7.0+ 上已基本消除“重写卡顿”和“fsync 阻塞主线程”的历史问题。
恢复时 multi-part AOF 怎么加载，有哪些坑
启动时，Redis 会按文件名顺序加载 base.aof，再依次回放所有 incr-*.aof。这个过程是原子的：只要任意一个增量文件缺失或校验失败，整个加载就会中止，并报错 Failed to load AOF: invalid incr AOF file。
容易忽略的关键点：
- 不要手动删除中间某个
incr-*.aof——这会导致后续文件无法加载；如需清理，应使用bgrewriteaof触发完整重写，生成新的base.aof和清空增量链 -
redis-check-aof工具目前不支持 multi-part 格式，强行运行会失败；校验必须靠 Redis 自身启动时完成 - 主从复制中，从节点首次同步仍走 RDB 快照；但后续增量同步会复用 multi-part 的
incr-*.aof结构，所以网络传输更细粒度，断点续传更可靠
真正复杂的不是机制本身，而是运维习惯——比如备份脚本硬编码了 appendonly.aof 路径，或者监控只盯单个文件大小，这些都会在 multi-part 启用后失效。
