Redis重启慢的根源是RDB文件大且AOF重放耗时，混合持久化（aof-use-rdb-preamble yes）通过在AOF开头嵌入RDB快照、尾部追加增量命令，实现“RDB全量+少量AOF重放”，显著提升加载速度；需同时开启appendonly yes和save规则，并执行bgrewriteaof生成新AOF文件。
Redis 重启慢，是因为 RDB 文件大 + AOF 重放耗时
Redis 重启加载慢的核心矛盾是：纯 RDB 模式恢复快但可能丢数据，纯 AOF 模式数据安全但重放命令极慢（尤其写密集场景）。混合持久化（aof-use-rdb-preamble yes）就是让 Redis 在 AOF 文件开头嵌入一个 RDB 快照，后续追加的命令仍走 AOF —— 加载时先用 RDB 快速构建初始状态，再只重放 AOF 尾部少量增量，大幅压缩加载时间。
开启混合持久化要改两个关键配置项
光设 aof-use-rdb-preamble yes 不够，它依赖 AOF 开启且 RDB 快照存在。必须同时满足：
-
appendonly yes—— AOF 必须启用，否则混合模式无意义 -
save ""或至少保留一个save规则（如save 900 1）—— RDB 快照需能生成，否则 preamble 部分为空 - 确认
aof-rewrite-incremental-fsync yes已开（默认），避免 AOF 重写时阻塞主线程影响稳定性
改完记得 redis-cli config rewrite 持久化配置，再 redis-cli bgrewriteaof 触发一次重写，生成带 RDB 前缀的新 AOF 文件。
加载速度提升多少？取决于 AOF 尾部增量大小
混合模式不是“绝对快”，而是把加载时间从 “RDB 全量 + AOF 全量重放” 降为 “RDB 全量 + AOF 尾部增量重放”。实际收益看业务写入节奏：
- 写入平稳（如每秒几百写）、AOF 重写频繁 → 尾部增量常在几 MB 内，加载可从分钟级降到秒级
- 写入爆发后立即重启 → 尾部可能达百 MB，重放仍需数秒，但比纯 AOF（GB 级）快一个数量级
- 禁用
auto-aof-rewrite-percentage或设置过高 → AOF 文件长期不重写，尾部膨胀，混合优势消失
用 redis-cli info persistence | grep -E "(aof_pending_rewrite|aof_current_size|aof_base_size)" 查当前 AOF 状态，重点关注 aof_current_size 和 aof_base_size 的比值。
容易被忽略的兼容性与故障点
混合持久化虽好，但几个边界情况必须手动验证：
- Redis 版本低于 4.0 → 不支持
aof-use-rdb-preamble，配置会静默忽略 - AOF 文件损坏时，Redis 会尝试跳过 preamble 直接解析 AOF，但若损坏点在 preamble 区域，可能直接启动失败，错误信息类似
Wrong signature trying to load DB from file - 从旧版升级后首次启用混合模式，必须执行
bgrewriteaof，否则老 AOF 文件无 preamble，加载仍走纯 AOF 路径 - 备份脚本若只拷贝
appendonly.aof，而没同步dump.rdb（虽然混合模式下 RDB 不用于加载，但某些监控或离线分析工具仍依赖它），可能引发误判
真正卡住人的，往往是重写触发时机和 AOF 文件实际结构 —— 别只信配置开了，要看 INFO persistence 里 aof_rewrite_in_progress 和 aof_last_bgrewrite_status 是否正常。
