Redis持久化方式详解：RDB与AOF原理

一、核心概念回顾

RDB vs AOF 对比

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

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

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

一条写命令进来，Redis 会同时干两件事：一边把数据写入内存，一边把命令记录到 AOF 日志。同时，RDB 快照按配置的时间间隔定时触发。整个过程可以这么看：

写命令 (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）是必须的。重写前后的变化如下：

重写前 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                     # 数据目录

# 快照触发条件（满足任一即触发）
sa ve 900 1                             # 900 秒内至少 1 个 key 变化
sa ve 300 10                            # 300 秒内至少 10 个 key 变化
sa ve 60 10000                          # 60 秒内至少 10000 个 key 变化

stop-writes-on-bgsa ve-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_bgsa ve_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 还会生成吗？	会，只要 sa ve 配置生效
Redis 4.0+ dump.rdb 有什么用？	备份、降级兼容、手动恢复
Redis 4.0+ 能删除 dump.rdb 吗？	可以，但不推荐（失去备份）
Redis 4.0+ 如何只保留一个文件？	配置 sa ve "" 禁用 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 快照 + 增量命令）。