关于Redis的持久化方式(RDB、AOF)

一、核心概念回顾

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 快照 + 增量命令)。

相关推荐
umeelove352 小时前
使用 Qt 插件和 SQLCipher 实现 SQLite 数据库加密与解密
数据库·qt·sqlite
不爱学英文的码字机器2 小时前
毫秒级破局:金仓数据库“连接条件下推”破解SQL性能困局
数据库·oracle
江沉晚呤时2 小时前
C#后端性能优化实战:Redis缓存 + 接口提速技巧
数据库·oracle
Y001112362 小时前
Day5-MySQL-SQL-4
数据库·sql·mysql
XW01059992 小时前
5-8能被3,5和7整除的数的个数(用集合实现)
前端·javascript·数据结构·数据库·python·for循环
我是玄兔2 小时前
第七章 数据库的设计
数据库
薛晓刚2 小时前
OpenClaw+Docker+KWDB3.1
数据库
倔强的石头_2 小时前
数据库迁移 TCO 全景账本:MySQL 替代中的隐性成本与工程化工具链实测
数据库
泯仲2 小时前
从零起步学习MySQL第十三章:MySQL 事务详解:原理、特性、并发问题与隔离级别
数据库·学习·mysql