RDB 恢复速度远快于 AOF：因 RDB 是压缩二进制快照，加载时直接构建内存结构，无命令解析与执行开销；AOF 需逐条重放文本命令，经历完整请求处理流程，文件更大、CPU/内存压力更高，恢复耗时显著增加。

RDB 恢复速度远快于 AOF

直接结论：RDB 恢复数据更快，尤其在数据量大时，差距明显。原因在于 RDB 是二进制快照文件，加载即用；AOF 是文本命令日志，必须逐条重放执行。

为什么 RDB 加载快？关键在文件结构和加载逻辑

RDB 文件是压缩的二进制序列化结果，Redis 启动时只需 mmap 或 read + 解析，把数据直接构建成内存结构。整个过程不涉及命令解析、参数校验、执行上下文创建等开销。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• dump.rdb 文件体积小（通常为原始数据的 30%–60%），磁盘读取耗时低
• 无命令执行链路，跳过 redisCommand 调度、ACL 检查、键过期判断等 runtime 步骤
• 恢复时间基本与数据集大小呈线性关系，10 GB 数据通常在秒级完成

AOF 恢复慢的根本原因：重放 ≠ 加载

AOF 恢复本质是“重新执行历史写操作”，哪怕只是 SET key value 这样的简单命令，也要走完整请求处理流程：协议解析 → 命令查找 → 参数验证 → 执行函数 → 写入 dict → 触发过期/淘汰逻辑。

• appendonly.aof 文件体积大（可能达原始数据 2–5 倍），尤其是未触发 bgrewriteaof 时
• 每条命令都需分配临时对象、更新统计指标、检查内存上限，CPU 和内存压力显著高于 RDB 加载
• 若 AOF 中包含大量 LPUSH、HSET 等批量操作，或存在冗余命令（如先 SET a 1 再 SET a 2），重放效率进一步下降

实际场景中容易被忽略的细节

很多人以为开启 AOF 就“更安全”，却没注意恢复阶段的不可控延迟。比如一个运行 7 天、QPS 5k 的实例，AOF 文件可能超 2 GB，重启恢复常需 3–8 分钟——这期间服务不可用，且无法中断或跳过。

• 即使配置了 auto-aof-rewrite-percentage，bgrewriteaof 本身会 fork 子进程，加剧内存压力，可能触发 OOM
• RDB 恢复失败（如文件损坏）通常报错明确（Invalid RDB magic number），而 AOF 恢复出错可能卡在某条命令，日志只显示 Unexpected EOF，排查成本高
• 混合持久化（aof-use-rdb-preamble yes）虽能缓解，但前提是 Redis ≥ 4.0，且仍需解析 RDB 前缀 + AOF 后缀两段逻辑