解读Redis的持久化方式(RDB、AOF)

来源：这里教程网时间：2026-04-01 13:11:24 作者：

一、核心概念回顾RDB vs AOF 对比二、同时开启 RDB+AOF 的工作机制1. 写入流程（双写机制）2. 混合持久化（Redis 4.0+ 核心特性）3. AOF 重写时的混合机制三、重启恢复优先级恢复顺序规则四、生产环境配置推荐完整配置示例五、两种模式对比模式一：传统双持久化（Redis 4.0 之前）模式二：混合持久化（Redis 4.0+ 推荐）六、实际场景演示场景：Redis 重启恢复七、最佳实践总结监控建议八、总结

一、核心概念回顾

RDB vs AOF 对比

特性RDB (快照)AOF (日志)原理定时全量快照记录每条写命令文件格式二进制 (.rdb)文本日志 (.aof)文件大小小大恢复速度快 (直接加载)慢 (重放命令)数据完整性可能丢失快照间数据可做到秒级甚至实时性能影响快照时 fork 子进程持续写磁盘，有开销

二、同时开启 RDB+AOF 的工作机制

1. 写入流程（双写机制）

┌─────────────────────────────────────────────────────────────────┐ │ Redis 写操作流程 │ └─────────────────────────────────────────────────────────────────┘ 写命令 (SET/DEL/HSET...) ↓ ┌───────────────┐ │ 内存数据 │ ← 立即执行 └───────┬───────┘ │ ┌───────┴───────┐ ↓ ↓ ┌──────────────┐ ┌──────────────┐ │ RDB 快照 │ │ AOF 日志 │ │ (定时触发) │ │ (实时追加) │ │ .rdb 文件 │ │ .aof 文件 │ └──────────────┘ └──────────────┘

关键点：

RDB：按配置的时间间隔触发（如 900 秒有 1 次修改）
AOF：每条写命令都记录（根据 fsync 策略决定何时落盘）

2. 混合持久化（Redis 4.0+ 核心特性）

这是最重要的配置！Redis 4.0 引入了 AOF-RDB 混合持久化：

┌─────────────────────────────────────────────────────────────────┐ │ 混合持久化文件格式 │ └─────────────────────────────────────────────────────────────────┘ appendonly.aof 文件结构： ┌─────────────────────────────────────────────────────────────────┐ │ 头部：RDB 格式快照数据 (全量数据) │ │ ───────────────────────────────────────────────────────────── │ │ 尾部：AOF 格式增量命令 (RDB 之后的写操作) │ │ ───────────────────────────────────────────────────────────── │ │ 结尾：EOF 标记 │ └─────────────────────────────────────────────────────────────────┘ 优势： ✓ 恢复时先加载 RDB 快照（快） ✓ 再重放少量 AOF 增量命令（数据完整） ✓ 兼顾速度和完整性

配置项：

# redis.conf aof-use-rdb-preamble yes # 开启混合持久化（Redis 4.0+ 默认开启）

3. AOF 重写时的混合机制

AOF 文件会越来越大，需要定期重写（Rewrite）：

┌─────────────────────────────────────────────────────────────────┐ │ AOF 重写流程 │ └─────────────────────────────────────────────────────────────────┘ 重写前 appendonly.aof： ┌─────────────────────────────────────────────────────────────────┐ │ RDB 快照 │ SET k1 v1 │ SET k1 v2 │ DEL k1 │ SET k2 v2 │ ... │ │ (旧数据) │ (重复命令很多，文件膨胀) │ └─────────────────────────────────────────────────────────────────┘ ↓ BGREWRITEAOF 触发重写后 appendonly.aof： ┌─────────────────────────────────────────────────────────────────┐ │ RDB 快照 (当前最新数据) │ SET k2 v2 │ (增量命令) │ │ (紧凑二进制) │ (少量新命令) │ └─────────────────────────────────────────────────────────────────┘ 结果： ✓ 文件体积大幅减小 ✓ 恢复速度更快 ✓ 数据不丢失

三、重启恢复优先级

恢复顺序规则

┌─────────────────────────────────────────────────────────────────┐ │ Redis 重启恢复流程 │ └─────────────────────────────────────────────────────────────────┘ Redis 启动 ↓ ┌───────────────────────┐ │ 检查持久化文件是否存在 │ └───────────┬───────────┘ │ ┌───────────────┼───────────────┐ ↓ ↓ ↓ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ AOF 存在 │ │ 仅 RDB │ │ 都无 │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ ↓ ↓ ↓ 优先用 AOF 用 RDB 恢复空数据库 (数据更完整) (快照数据) (无历史数据) │ │ │ └──────────────┴──────────────┘ ↓ ┌─────────────────┐ │ 恢复完成 │ │ 对外提供服务 │ └─────────────────┘

核心原则：

AOF 优先级 > RDB 优先级原因：AOF 数据通常比 RDB 更完整（丢失数据更少）

四、生产环境配置推荐

完整配置示例

# ==================== RDB 配置 ==================== dbfilename dump.rdb # RDB 文件名 dir /var/lib/redis # 数据目录 # 快照触发条件（满足任一即触发） save 900 1 # 900 秒内至少 1 个 key 变化 save 300 10 # 300 秒内至少 10 个 key 变化 save 60 10000 # 60 秒内至少 10000 个 key 变化 stop-writes-on-bgsave-error yes # RDB 失败时停止写入 rdbcompression yes # 压缩 RDB 文件 rdbchecksum yes # 校验和 # ==================== AOF 配置 ==================== appendonly yes # 开启 AOF appendfilename "appendonly.aof" # AOF 文件名 # AOF 落盘策略（三选一） appendfsync everysec # 推荐：每秒同步（性能与安全平衡） # appendfsync always # 每次写都同步（最安全，性能差） # appendfsync no # 由系统决定（性能最好，可能丢数据） no-appendfsync-on-rewrite no # 重写时是否禁用 fsync auto-aof-rewrite-percentage 100 # AOF 增长 100% 时触发重写 auto-aof-rewrite-min-size 64mb # AOF 最小 64MB 才触发重写 # ==================== 混合持久化 ==================== aof-use-rdb-preamble yes # 开启混合持久化（关键！）

五、两种模式对比

模式一：传统双持久化（Redis 4.0 之前）

┌─────────────────────────────────────────────────────────────────┐ │ 传统双持久化 │ └─────────────────────────────────────────────────────────────────┘ 文件结构： ┌─────────────────────┐ ┌─────────────────────────────────┐ │ dump.rdb │ │ appendonly.aof │ │ (独立 RDB 文件) │ │ (纯 AOF 日志，无 RDB 前缀) │ │ 全量快照 │ │ 所有写命令 │ └─────────────────────┘ └─────────────────────────────────┘ 恢复时： 1. 优先加载 AOF 文件 2. 逐条重放所有命令 3. RDB 文件仅作为备份缺点： ✗ AOF 文件大 ✗ 恢复慢 ✗ 两份文件独立管理

模式二：混合持久化（Redis 4.0+ 推荐）

┌─────────────────────────────────────────────────────────────────┐ │ 混合持久化 │ └─────────────────────────────────────────────────────────────────┘ 文件结构： ┌─────────────────────────────────────────────────────────────────┐ │ appendonly.aof (唯一持久化文件) │ │ ┌─────────────────┬───────────────────────────────────────┐ │ │ │ RDB 快照部分 │ AOF 增量命令部分 │ │ │ │ (二进制格式) │ (文本命令格式) │ │ │ │ 基础数据 │ RDB 之后的写操作 │ │ │ └─────────────────┴───────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ 恢复时： 1. 加载 RDB 快照部分（快速） 2. 重放 AOF 增量命令（少量） 3. dump.rdb 文件不再使用优点： ✓ 恢复速度快 ✓ 数据完整性高 ✓ 文件管理简单

六、实际场景演示

场景：Redis 重启恢复

时间线： T0: Redis 启动，开启 RDB+AOF 混合持久化 T1: 写入 100 万条数据 T2: 触发 RDB 快照 → dump.rdb 生成 T3: AOF 持续记录写命令 T4: AOF 重写 → appendonly.aof 包含 RDB 快照 + 增量命令 T5: Redis 宕机 T6: Redis 重启恢复过程： ┌─────────────────────────────────────────────────────────────────┐ │ 步骤 1: 检测文件 │ │ - 发现 appendonly.aof 存在 │ │ - 发现 dump.rdb 存在（但不用） │ ├─────────────────────────────────────────────────────────────────┤ │ 步骤 2: 加载 AOF 文件 │ │ - 读取 RDB 前缀部分 → 恢复 100 万条基础数据 (约 2 秒) │ │ - 重放 AOF 增量命令 → 恢复 T4-T5 期间的写操作 (约 0.5 秒) │ ├─────────────────────────────────────────────────────────────────┤ │ 步骤 3: 恢复完成 │ │ - 总耗时约 2.5 秒 │ │ - 数据丢失：仅 T5 时刻未 fsync 的少量数据 │ └─────────────────────────────────────────────────────────────────┘ 对比纯 RDB 恢复： - 恢复时间：约 2 秒 - 数据丢失：T2-T5 期间所有写操作（可能几小时数据）对比纯 AOF 恢复： - 恢复时间：约 30 秒+（重放所有命令） - 数据丢失：仅 T5 时刻未 fsync 的少量数据

七、最佳实践总结

场景推荐配置理由生产环境RDB+AOF 混合持久化性能与安全最佳平衡高写入场景appendfsync everysec每秒同步，性能影响小金融级数据appendfsync always不丢数据，接受性能损失纯缓存场景可关闭持久化追求极致性能Redis 版本4.0+支持混合持久化

监控建议

# 检查持久化状态 redis-cli INFO persistence # 关键指标： # - rdb_last_bgsave_status: RDB 最后保存状态 # - aof_enabled: AOF 是否开启 # - aof_last_rewrite_time_sec: AOF 最后重写耗时 # - aof_current_size: AOF 当前文件大小

八、总结

问题答案RDB 和 AOF 能同时开吗？可以，且生产环境推荐同时开启恢复时优先用哪个？AOF 优先级更高（数据更完整）混合持久化是什么？AOF 文件头部存 RDB 快照，尾部存增量命令需要配置什么？aof-use-rdb-preamble yes（4.0+ 默认开启）最佳实践？Redis 4.0+ 使用混合持久化 + appendfsync everysecRedis 4.0+ 有几个持久化文件？两个：dump.rdb + appendonly.aofRedis 4.0+ appendonly.aof 内容是什么？RDB 快照前缀 + AOF 增量命令Redis 4.0+ dump.rdb 还会生成吗？会，只要 save 配置生效Redis 4.0+ dump.rdb 有什么用？备份、降级兼容、手动恢复Redis 4.0+ 能删除 dump.rdb 吗？可以，但不推荐（失去备份）Redis 4.0+ 如何只保留一个文件？配置 save "" 禁用 RDB（不推荐） Redis 版本持久化模式dump.rdbappendonly.aof恢复时使用哪个4.0 之前仅 RDB✓ 存在✗ 不存在RDB4.0 之前仅 AOF✗ 不存在✓ 存在AOF4.0 之前RDB+AOF✓ 存在✓ 存在AOF（优先）4.0+混合持久化✓ 存在✓ 存在AOF（含 RDB 前缀）

核心要点：

Redis 4.0+ 的混合持久化是生产环境的标准配置，它巧妙地将 RDB 的快速恢复和 AOF 的数据完整性结合起来，通过单一的 AOF 文件同时存储快照和增量日志，实现了性能和安全的最优平衡。Redis 4.0+ 混合持久化后，dump.rdb 和 appendonly.aof 两个文件都会存在。dump.rdb 虽然恢复时不用，但仍然作为独立备份存在，提供降级兼容和冷备能力。appendonly.aof 才是真正用于恢复的主文件（包含 RDB 快照 + 增量命令）。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。