必须先启用aof再设置aof-use-rdb-preamble yes，否则无效；该参数仅在aof重写时生效，依赖appendonly yes、合理重写阈值及可写appendfilename等前提，混合格式仅存在于重写后的新aof文件开头。
必须先开启 AOF，再设 aof-use-rdb-preamble yes，否则配置无效。 Redis 6.0 默认仍不启用混合持久化（除非你用的是 5.0+ 的某些发行版预编译包），aof-use-rdb-preamble 本身只是个“开关”，它只在 AOF 重写（bgrewriteaof）发生时起作用——而重写前提是 AOF 已启用且有数据可写。
确认并启用 AOF 是前置硬条件
混合持久化不是独立功能，而是 AOF 重写的增强模式。没 AOF 就没有重写，也就谈不上混合。
- 检查当前是否启用 AOF：
CONFIG GET appendonly，返回"yes"才行；若为"no"，先执行CONFIG SET appendonly yes - 确保
appendfilename存在且路径可写（如"appendonly.aof"），否则重写会失败 - 如果之前从未开过 AOF，首次启用后需至少有一次写操作，再触发
bgrewriteaof，混合结构才会生成
设置 aof-use-rdb-preamble 并验证生效
该参数仅控制重写行为，不改变运行时逻辑。设了不等于立刻生效，要看下一次重写时机。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 命令行临时设置：
CONFIG SET aof-use-rdb-preamble yes（重启失效） - 永久生效：编辑
redis.conf，确保有这两行（顺序无关，但建议 AOF 在前）：appendonly yes<br>aof-use-rdb-preamble yes
- 验证是否生效：
CONFIG GET aof-use-rdb-preamble返回"yes"；再执行bgrewriteaof，观察日志是否有Background AOF rewrite started和后续成功提示 - 注意：旧的
appendonly.aof文件仍是纯文本格式，混合结构只出现在重写后的新文件中
为什么重写后 AOF 文件开头是乱码
这不是损坏，是 RDB preamble 的正常表现。Redis 加载时靠 magic 字符串（如 REDIS0011）识别二进制头。
- 用
head -c 20 appendonly.aof | hexdump -C可看到开头类似52 45 44 49 53 30 30 31 31（即 "REDIS0011" 的 ASCII 十六进制） - 不要用
cat或文本编辑器直接打开混合 AOF——后半段命令是明文，前半段是二进制，显示错乱属预期行为 - 加载时 Redis 内部会先调用 RDB 解析器处理 preamble，再切换到 AOF 解析器处理剩余命令行
- 若 preamble 损坏（如磁盘写满中断重写），且
aof-load-truncated yes（默认开启），则自动降级为纯 AOF 恢复
影响混合效果的关键配套配置
光开 aof-use-rdb-preamble 不够，AOF 重写得真正跑起来，否则永远用不上 RDB 部分。
-
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size必须合理：例如设为100和64mb，但若业务写入极少，AOF 长期卡在 20mb，就不会触发重写 -
no-appendfsync-on-rewrite yes强烈建议开启：避免重写期间appendfsync everysec被阻塞，导致主线程延迟飙升 -
aof-load-truncated yes保持默认：保证 preamble 截断时能 fallback 到安全恢复路径 - RDB 相关错误（如
stop-writes-on-bgsave-error yes）会影响重写——若 RDB 序列化阶段因磁盘满失败，整个bgrewriteaof中止，AOF 保持纯文本状态
混合持久化的实际价值体现在重启加载阶段：RDB preamble 部分加载快，AOF 增量部分语义保全。但它的“生效窗口”完全依赖 AOF 重写是否活跃——一个长期不重写的实例，哪怕配置全对，也等同于纯 AOF。
