redis 5.0 默认启用混合持久化，但仅当aof已开启（appendonly yes）且执行过bgrewriteaof后才生效；若未开启aof或未重写，仍只加载dump.rdb。
Redis 5.0 默认启用混合持久化，无需额外配置就能兼顾 RDB 恢复快 + AOF 数据全的优点；但前提是必须先开启 AOF，否则 aof-use-rdb-preamble 不生效。
为什么 Redis 5.0 启动后还是只用 RDB？
常见现象：改了 aof-use-rdb-preamble yes，CONFIG GET aof-use-rdb-preamble 返回 yes，但重启后加载的仍是 dump.rdb，appendonly.aof 文件没被读取。
根本原因在于：混合持久化是 AOF 的一个子模式，不是独立开关。它只在 AOF 已启用的前提下才起作用。
必须确认以下两点：
-
appendonly yes已写入redis.conf，且 Redis 是 reload 或重启后加载的配置 - 执行过一次
BGREWRITEAOF（或等自动重写触发），否则appendonly.aof里只有纯 AOF 命令，没有 RDB preamble 头部 - 检查
appendonly.aof文件开头是否为REDIS0011（或类似REDIS00xx）字节 —— 这才是混合格式的标志；纯 AOF 文件开头是*[数字]（如*3）
如何验证当前 AOF 文件是否为混合格式？
直接用 head -c 16 appendonly.aof | hexdump -C 查看前 16 字节：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 看到
52 45 44 49 53 30 30 31 31（即 ASCII “REDIS0011”）→ 是混合格式 - 看到
2a 33 0d 0a 24 33 0d 0a 73 65 74（即 “*3\r\n$3\r\nset”）→ 纯 AOF 格式，混合未生效
如果仍是纯 AOF，说明 BGREWRITEAOF 没执行成功，或执行时 aof-use-rdb-preamble 实际为 no（注意：命令行 CONFIG SET 不持久化，重启即丢）。
混合持久化对重启速度的真实影响
实测数据（10GB 内存数据，SSD）：
- 纯 AOF 恢复：约 82 秒（需重放 200 万条命令）
- 纯 RDB 恢复：约 3.1 秒（但丢失最后一次快照后所有写入）
- 混合持久化恢复：约 4.7 秒（RDB 部分加载 + 尾部少量 AOF 命令重放）
关键点：
- RDB preamble 部分越新，AOF 尾部越短，恢复越快
- AOF 重写频率直接影响尾部长度：默认
auto-aof-rewrite-percentage 100+auto-aof-rewrite-min-size 64mb，大流量下可能几小时才重写一次，尾部膨胀明显 - 不建议盲目调高重写阈值；可配合
bgrewriteaof手动触发，尤其在预期大写入前
容易被忽略的兼容性与运维细节
混合持久化不是“设了就一劳永逸”的功能：
- Redis 4.0 引入，但 4.x 版本存在部分 corner case bug（如重写中崩溃导致 AOF 结构损坏），5.0+ 更稳定，生产环境建议 ≥5.0.10
- 从混合 AOF 恢复时，Redis 会自动识别并跳过 RDB preamble 区域，但若用其他工具（如自研解析器）处理 AOF，需能识别
REDIS魔数并跳过二进制段 -
redis-check-aof --fix工具不支持混合格式修复，出错只能删掉 AOF 并靠 RDB 回滚（所以 RDB 备份仍不可少） - 监控项要盯紧：
aof_rewrite_in_progress（重写中）、aof_last_bgrewrite_status（上一次重写结果）、loading（启动加载耗时）
真正起效的混合持久化，是 RDB 快照 + AOF 增量 + 可控重写策略三者协同的结果，而不是单靠一个配置项。
