解读Redis的持久化方式(RDB、AOF)_F11 - 专业站长和开发者的学习网站

一、核心概念回顾

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 增量命令（数据完整）

? 兼顾速度和完整性

配置项：

1 2	# 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 everysec
Redis 4.0+ 有几个持久化文件？	两个：dump.rdb + appendonly.aof
Redis 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.rdb	appendonly.aof	恢复时使用哪个
4.0 之前	仅 RDB	? 存在	? 不存在	RDB
4.0 之前	仅 AOF	? 不存在	? 存在	AOF
4.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 快照 + 增量命令）。