Redis 7.0的Multi-Part AOF需同时满足aof-use-rdb-preamble为no、appenddirname下存在base.aof/incr-*.aof/appendonly.aof.manifest三类文件、日志显示incr AOF创建或base重写，才真正生效。
Redis 7.0 引入 Multi-Part AOF 不是为了替换旧 AOF，而是为了解决高写入场景下重写期间的内存暴涨、主线程卡顿和恢复慢这三大实际问题。它默认开启，但极易因配置错误退化回旧模式，导致你“以为开了，其实没开”。
CONFIG GET aof-use-rdb-preamble 返回 yes 就说明没生效
这是最常被忽略的开关。只要 aof-use-rdb-preamble 是 yes，Redis 就会走 Redis 6.x 的混合模式（RDB preamble + 单 AOF 文件），完全绕过 Multi-Part AOF 的所有优势。
- 必须执行
CONFIG SET aof-use-rdb-preamble no，并写入 redis.conf 持久化 - 仅靠
appendonly yes不足以启用 Multi-Part AOF - 升级后若未触发重写，目录下仍只有
appendonly.aof，不代表失效，而是尚未切换；需手动执行BGREWRITEAOF触发首次 multi-part 生成
appenddirname 必须独立配置且不可与 dir 混用
Multi-Part AOF 会把 base.aof、incr-*.aof 和 appendonly.aof.manifest 全部写入 appenddirname 目录。如果没配或配成和 dir 相同路径，会导致文件混放 —— 运维脚本按 *.aof 清理时可能误删 manifest，直接导致启动失败。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在 redis.conf 中显式设置：
appenddirname /var/lib/redis/aof - 确保该路径磁盘有足够空间，并单独监控（不能只看
dir所在磁盘） -
appenddirname目录权限需与dir一致，否则 Redis 启动报错Failed to open AOF manifest file
验证是否真正在用 Multi-Part AOF 要三者同时满足
只看版本号或只查一个指标，大概率误判。必须同时确认配置、文件、日志三项：
-
CONFIG GET aof-use-rdb-preamble返回no - 在
appenddirname下能看到至少三个文件：base.aof（或*.base.rdb）、一个以上incr-*.aof、以及appendonly.aof.manifest - 日志中出现类似
Creating new incr AOF file incr-0000000001.aof或Starting automatic rewriting of AOF on base.aof size
manifest.aof 损坏 = 启动失败，但它极小且易被忽略
appendonly.aof.manifest 是整个 Multi-Part AOF 恢复链的唯一入口，大小通常不到 1KB，但一旦损坏或丢失，Redis 直接 abort，不会尝试 fallback 到旧逻辑。
- 不要手动编辑、移动或 chmod 它；Redis 写入是原子的，外部干预极易破坏 JSON 结构
- 备份策略应单独针对该文件（例如每小时
cp /var/lib/redis/aof/appendonly.aof.manifest /backup/manifest-$(date +%s)） - 某些容器化部署中，若挂载点未覆盖
appenddirname，manifest 可能落在 tmpfs 里，重启即丢
真正落地时，最难的不是配置开关，而是让运维体系意识到：manifest.aof 比任何单个 incr-*.aof 都关键，而 appenddirname 是一个需要独立保障的磁盘路径，不是可有可无的附属目录。
