一、核心概念回顾
RDB vs AOF 对比
| 特性 | RDB (快照) | AOF (日志) |
|---|---|---|
| 原理 | 定时全量快照 | 记录每条写命令 |
| 文件格式 | 二进制 (.rdb) | 文本日志 (.aof) |
| 文件大小 | 小 | 大 |
| 恢复速度 | 快 (直接加载) | 慢 (重放命令) |
| 数据完整性 | 可能丢失快照间数据 | 可做到秒级甚至实时 |
| 性能影响 | 快照时 fork 子进程 | 持续写磁盘,有开销 |
二、同时开启 RDB+AOF 的工作机制
1. 写入流程(双写机制)
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ Redis 写操作流程 │
└─────────────────────────────────────────────────────────────────┘
写命令 (SET/DEL/HSET...)
↓
┌───────────────┐
│ 内存数据 │ ← 立即执行
└───────┬───────┘
│
┌───────┴───────┐
↓ ↓
┌──────────────┐ ┌──────────────┐
│ RDB 快照 │ │ AOF 日志 │
│ (定时触发) │ │ (实时追加) │
│ .rdb 文件 │ │ .aof 文件 │
└──────────────┘ └──────────────┘
关键点:
-
RDB:按配置的时间间隔触发(如 900 秒有 1 次修改)
-
AOF:每条写命令都记录(根据 fsync 策略决定何时落盘)
2. 混合持久化(Redis 4.0+ 核心特性)
这是最重要的配置!Redis 4.0 引入了 AOF-RDB 混合持久化:
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ 混合持久化文件格式 │
└─────────────────────────────────────────────────────────────────┘
appendonly.aof 文件结构:
┌─────────────────────────────────────────────────────────────────┐
│ 头部:RDB 格式快照数据 (全量数据) │
│ ───────────────────────────────────────────────────────────── │
│ 尾部:AOF 格式增量命令 (RDB 之后的写操作) │
│ ───────────────────────────────────────────────────────────── │
│ 结尾:EOF 标记 │
└─────────────────────────────────────────────────────────────────┘
优势:
✓ 恢复时先加载 RDB 快照(快)
✓ 再重放少量 AOF 增量命令(数据完整)
✓ 兼顾速度和完整性
配置项:
bash
# redis.conf
aof-use-rdb-preamble yes # 开启混合持久化(Redis 4.0+ 默认开启)
3. AOF 重写时的混合机制
AOF 文件会越来越大,需要定期重写(Rewrite):
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ AOF 重写流程 │
└─────────────────────────────────────────────────────────────────┘
重写前 appendonly.aof:
┌─────────────────────────────────────────────────────────────────┐
│ RDB 快照 │ SET k1 v1 │ SET k1 v2 │ DEL k1 │ SET k2 v2 │ ... │
│ (旧数据) │ (重复命令很多,文件膨胀) │
└─────────────────────────────────────────────────────────────────┘
↓ BGREWRITEAOF 触发
重写后 appendonly.aof:
┌─────────────────────────────────────────────────────────────────┐
│ RDB 快照 (当前最新数据) │ SET k2 v2 │ (增量命令) │
│ (紧凑二进制) │ (少量新命令) │
└─────────────────────────────────────────────────────────────────┘
结果:
✓ 文件体积大幅减小
✓ 恢复速度更快
✓ 数据不丢失
三、重启恢复优先级
恢复顺序规则
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ Redis 重启恢复流程 │
└─────────────────────────────────────────────────────────────────┘
Redis 启动
↓
┌───────────────────────┐
│ 检查持久化文件是否存在 │
└───────────┬───────────┘
│
┌───────────────┼───────────────┐
↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ AOF 存在 │ │ 仅 RDB │ │ 都无 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
↓ ↓ ↓
优先用 AOF 用 RDB 恢复 空数据库
(数据更完整) (快照数据) (无历史数据)
│ │ │
└──────────────┴──────────────┘
↓
┌─────────────────┐
│ 恢复完成 │
│ 对外提供服务 │
└─────────────────┘
核心原则:
AOF 优先级 > RDB 优先级
原因:AOF 数据通常比 RDB 更完整(丢失数据更少)
四、生产环境配置推荐
完整配置示例
bash
# ==================== 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 之前)
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ 传统双持久化 │
└─────────────────────────────────────────────────────────────────┘
文件结构:
┌─────────────────────┐ ┌─────────────────────────────────┐
│ dump.rdb │ │ appendonly.aof │
│ (独立 RDB 文件) │ │ (纯 AOF 日志,无 RDB 前缀) │
│ 全量快照 │ │ 所有写命令 │
└─────────────────────┘ └─────────────────────────────────┘
恢复时:
1. 优先加载 AOF 文件
2. 逐条重放所有命令
3. RDB 文件仅作为备份
缺点:
✗ AOF 文件大
✗ 恢复慢
✗ 两份文件独立管理
模式二:混合持久化(Redis 4.0+ 推荐)
TypeScript
┌─────────────────────────────────────────────────────────────────┐
│ 混合持久化 │
└─────────────────────────────────────────────────────────────────┘
文件结构:
┌─────────────────────────────────────────────────────────────────┐
│ appendonly.aof (唯一持久化文件) │
│ ┌─────────────────┬───────────────────────────────────────┐ │
│ │ RDB 快照部分 │ AOF 增量命令部分 │ │
│ │ (二进制格式) │ (文本命令格式) │ │
│ │ 基础数据 │ RDB 之后的写操作 │ │
│ └─────────────────┴───────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
恢复时:
1. 加载 RDB 快照部分(快速)
2. 重放 AOF 增量命令(少量)
3. dump.rdb 文件不再使用
优点:
✓ 恢复速度快
✓ 数据完整性高
✓ 文件管理简单
六、实际场景演示
场景:Redis 重启恢复
TypeScript
时间线:
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+ | 支持混合持久化 |
监控建议
bash
# 检查持久化状态
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 快照 + 增量命令)。