混合持久化不是独立功能，而是AOF重写时的增强模式；必须先启用appendonly yes，再设置aof-use-rdb-preamble yes，且仅在bgrewriteaof触发后生成RDB头+AOF尾的混合文件。
aof-use-rdb-preamble 不是独立功能，它只在 AOF 重写时生效，且必须依赖 appendonly yes。单独设成 yes 但没开 AOF，混合模式根本不会启动。
必须先确认 appendonly 已启用
混合持久化本质是 AOF 的增强模式，不是 RDB 和 AOF 的“并行双写”。如果 appendonly no，Redis 根本不生成或重写 appendonly.aof，aof-use-rdb-preamble 就像给一辆没油的车调喷油嘴——没意义。
检查方式：
redis-cli config get appendonly
返回 ["appendonly","yes"] 才算过关。若为 "no"，先改配置或执行：
redis-cli config set appendonly yes
注意：该命令需配合 CONFIG REWRITE 或重启才能持久化到 redis.conf。
再设置 aof-use-rdb-preamble yes 并验证
这个参数默认在 Redis 5.0+ 是 yes，但 4.x 多数为 no，旧配置迁移时极易被忽略。
- 临时生效（重启失效）：
redis-cli config set aof-use-rdb-preamble yes
- 永久生效：编辑
redis.conf，确保这一行存在且值为yes：aof-use-rdb-preamble yes
- 验证是否真正生效：
redis-cli config get aof-use-rdb-preamble
，输出必须是["aof-use-rdb-preamble","yes"]
别信配置文件里写了就等于开了——Redis 启动时若读取失败或语法错误，会静默 fallback 到默认值。
触发 bgrewriteaof 才能生成混合格式文件
设置了参数 ≠ 立刻生效。混合结构只出现在下一次 bgrewriteaof 成功执行后的 appendonly.aof 中。已有纯文本 AOF 文件不会自动转换。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
手动触发并观察效果：
redis-cli bgrewriteaof
等几秒后检查文件开头：
xxd -l 32 appendonly.aof
如果看到 52 45 44 49 53 30 30 31 31（即 REDIS0011）这类二进制魔数，说明 RDB 前缀已写入；后面若跟着 *3\r\n$3\r\nSET 这类明文命令，就是标准混合结构。
常见误区：
-
cat appendonly.aof看到乱码 + 部分明文 → 正常，不是损坏 - 执行了
bgrewriteaof但文件还是纯文本 → 检查aof-use-rdb-preamble是否真为yes，以及是否发生重写失败（看 Redis 日志里有没有Failed to rewrite the AOF）
务必注释掉所有 save 规则
很多人开了混合持久化，却保留着 save 900 1 这类配置，结果 Redis 既 fork 子进程写 dump.rdb，又在 appendonly.aof 里塞一份 RDB 二进制块——磁盘白占一倍，fork 压力翻倍，还可能因磁盘满导致 bgrewriteaof 中断。
正确做法是：
- 把所有
save行注释掉，例如：# save 900 1
- 或显式禁用：
save ""
- 确保
rdbcompression、rdbchecksum这些 RDB 相关配置也无需关注，因为 RDB 快照本身已退场
混合模式下，dump.rdb 文件完全多余；只要 appendonly.aof 存在且完整，重启就能全量恢复 + 增量补全——这才是设计本意。
最容易被忽略的一点：混合持久化不改变 AOF 重写的触发逻辑。如果 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 设得太高，或者业务写入极低，AOF 可能几个月都不重写一次，那 aof-use-rdb-preamble 就一直躺在配置里睡大觉。
