开启aof-use-rdb-preamble yes仅启用混合格式（RDB头+增量命令），不等于启用Redis 7.0的多文件增量重写；后者需base/incr/manifest文件结构协同aof-rewrite-incremental-fsync等参数才生效。
aof-use-rdb-preamble yes 是 Redis 7.0 增量 AOF 重写的前提，但仅设它还不够——新版 AOF 多文件结构（base/incr/manifest）必须配合 aof-rewrite-incremental-fsync 和 aof-load-truncated 等参数协同生效。
为什么开 aof-use-rdb-preamble 不等于自动启用“增量重写”
很多人以为把 aof-use-rdb-preamble 设为 yes 就启用了“增量重写”，其实不是。这个配置只控制是否在重写后的 AOF 文件头部嵌入一个 RDB 快照（即混合格式），它解决的是加载速度和数据完整性问题，而非重写过程本身的增量性。
Redis 7.0 的真正“增量重写”依赖底层新 AOF 文件组织方式：重写不再生成单个大文件，而是拆成 base.aof（全量快照）、多个 incr_*.aof（增量日志）和一个 manifest.aof（元数据索引）。这个机制默认开启，但需确保以下条件：
-
aof-use-rdb-preamble yes—— 否则 base.aof 不含 RDB preamble，无法被快速识别和加载 -
aof-rewrite-incremental-fsync yes—— 控制重写过程中是否分批 fsync，避免单次 IO 阻塞过长（默认yes，建议保持） -
aof-load-truncated yes—— 允许加载被截断的 incr 文件（网络中断或 crash 后恢复更鲁棒） - 禁用旧式单文件模式：
aof-auto-sync-rewrite no（该参数已废弃，但若手动设为yes可能干扰 manifest 逻辑）
如何验证当前 AOF 是否走的是多文件增量重写路径
直接检查 Redis 数据目录下的文件结构比看配置更可靠。执行一次 BGREWRITEAOF 后，观察目录输出：
ls -1 ./data/ base.aof incr_0000000001.aof incr_0000000002.aof manifest.aof
如果看到以上四类文件（尤其有多个 incr_*.aof），说明已进入新版多文件流程；如果只有 appendonly.aof，说明仍走旧逻辑——大概率是 aof-use-rdb-preamble 没生效，或 Redis 版本未真正升级到 7.0+（可用 redis-server --version 确认）。
注意：appendfilename 配置在 7.0+ 中已失效，它只影响旧单文件模式；新结构下文件名由 Redis 内部管理，不可自定义。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
重写触发后，aof-use-rdb-preamble 如何影响 base.aof 内容
这个参数决定 base.aof 文件开头是否以 REDIS0011（或对应版本标识）二进制字符串开头：
- 设为
yes：base.aof 开头是完整 RDB 格式，后续紧跟 AOF 命令（如 *2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n）；Redis 加载时先解析 RDB 部分，再顺序执行 AOF 尾部命令，恢复更快、更准 - 设为
no：base.aof 纯文本 AOF 格式，无 RDB preamble；加载时需逐条 replay 所有命令，耗时长且对损坏更敏感
实操中，no 模式下若某条命令语法错误（如 SET key 缺 value），整个 AOF 加载失败；而 yes 模式下即使尾部 AOF 损坏，RDB 部分仍可加载，数据不全丢。
容易忽略的兼容性陷阱
Redis 7.0 的多文件 AOF 不能被 6.x 或更早版本读取——哪怕你把 base.aof 单独拷过去，老版本 Redis 启动时会报错：Invalid AOF header 或直接 abort。
迁移前必须确认：
- 所有哨兵、集群节点、备份脚本都已升级至 7.0+
- 监控脚本若依赖
appendonly.aof文件大小判断重写进度，需改用INFO persistence中的aof_current_size和aof_base_size字段 -
CONFIG GET aof-use-rdb-preamble返回值为yes，不代表当前正在运行的 AOF 就是混合格式——它只影响下一次重写行为；已有旧 AOF 文件不会自动转换
最稳妥的做法：停机后清空旧 appendonly.aof，重启并触发一次 BGREWRITEAOF，再验证文件结构。
