Redis 4.0混合持久化仅在AOF重写时生效，需同时启用RDB（如配置save或执行过SAVE/BGSAVE），否则生成的AOF仍为纯文本；触发需先确保dump.rdb存在，再执行BGREWRITEAOF，头部出现REDIS0009即生效。
Redis 4.0 的混合持久化（aof-use-rdb-preamble yes）不是“开了就稳”，它只在 AOF 重写时生效，且依赖 RDB 快照作为前缀——这意味着你必须同时启用 RDB（至少保留 save 配置或触发过 SAVE/BGSAVE），否则重写后的 AOF 文件仍是纯文本格式，起不到加速加载的作用。
混合持久化怎么触发？不是配置完就自动生效
混合持久化只在 AOF 重写（bgrewriteaof）过程中生效，前提是：aof-use-rdb-preamble yes 已开启，且当前 Redis 实例能成功生成 RDB 快照（即 save 配置未被完全禁用，或手动执行过 SAVE）。如果 Redis 启动后从未产生过 RDB 文件（比如把所有 save 行注释掉，又没手动调过 SAVE），那么即使开了混合模式，重写出来的 AOF 仍是纯 AOF 格式，开头没有 RDB 二进制段。
- 检查是否已有 RDB：确认
dump.rdb文件存在且时间合理（ls -l dump.rdb） - 强制触发一次 RDB：执行
redis-cli SAVE（阻塞）或redis-cli BGSAVE（推荐） - 再触发 AOF 重写：执行
redis-cli BGREWRITEAOF，之后查看新 AOF 文件头：head -c 100 appendonly.aof | hexdump -C，若开头是REDIS0009（或对应版本号），说明 RDB 前缀已写入
加载时如何识别混合 AOF？RDB 段和 AOF 段怎么分界
Redis 启动时读取 AOF 文件，先尝试解析头部是否为合法 RDB 格式（魔数 REDIS + 版本号）。如果是，则按 RDB 协议加载前半部分，加载完成后继续按 AOF 协议逐条回放后续命令。整个过程对用户透明，但有两点关键行为：
- RDB 段加载失败（如损坏、版本不兼容），Redis 直接报错退出，不会降级为纯 AOF 解析
- AOF 段中若含非法命令（如语法错误、key 不存在的
EXPIREAT），会跳过该行并记录 warning，不影响整体加载 - 加载耗时 ≈ RDB 加载时间 + AOF 回放时间，但 RDB 段通常比等效的逐条 AOF 执行快 3–5 倍（尤其大数据集）
哪些配置组合会让混合持久化“形同虚设”
以下常见配置会使混合持久化无法发挥效果，甚至导致加载失败：
-
save ""或全部注释掉save行 → Redis 无 RDB 能力，bgrewriteaof仍会执行，但生成纯 AOF -
aof-use-rdb-preamble yes但appendonly no→ AOF 关闭，自然不触发重写，混合无意义 - RDB 版本不匹配：比如用 Redis 6.x 生成的 RDB 前缀，被 Redis 4.0 实例加载 → 报错
Wrong RDB version，启动失败 - AOF 文件权限异常或磁盘满导致重写中途失败 → 新 AOF 文件可能截断，开头 RDB 不完整，加载时报
Invalid RDB header
混合持久化的真正价值在重启恢复阶段：它把“全量快照加载 + 增量日志回放”的两步合并成单文件顺序读取，但这个优势完全依赖 RDB 前缀的完整性与可加载性。别只盯着配置项开关，得验证 RDB 是否真被写进了 AOF 头部——用 hexdump 看一眼最实在。
