解读Redis的持久化方式(RDB、AOF)
更新时间：2026年04月01日 10:44:07 作者：大手你不懂
文章主要介绍了Redis的RDB和AOF两种持久化机制的区别、工作原理和优点,并详细讲解了Redis 4.0+版本中RDB+AOF混合持久化的实现方式、配置建议和实际应用,强调了混合持久化在生产环境中的重要性和配置要点,以及在不同场景下的推荐配置策略
一、核心概念回顾
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 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 快照 + 增量命令）。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
本文主要介绍了Redis队列和阻塞队列的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-11-11
本文主要介绍了redis序列化及各种序列化情况划分，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2023-04-04
在现代分布式系统中,Redis作为高性能的内存数据库,常用于缓存、消息队列和实时数据处理,合理使用Redis数据结构,可以极大提升系统性能,本文将通过一个实际案例,介绍如何将Redis存储结构从 Set 迁移到Hash,并实现定时任务监控数据变化,需要的朋友可以参考下2025-06-06
Redis模糊查询应避免KEYS,改用SCAN非阻塞迭代,优先优化键结构（如IndexSet、SortedSet）,提升效率,复杂场景可结合外部搜索引擎,平衡内存、延迟及实时性需求,本文给大家介绍redis中数据模糊查询scan用法,感兴趣的朋友一起看看吧2025-09-09
本文主要介绍了Redis中Bitmap的使用示例，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2022-05-05
今天小编就为大家分享一篇解决redis修改requirepass后不生效的问题，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2018-05-05
本文主要介绍了Redis 数据迁移的项目实践,通过Redis-shake的sync（同步）模式,可以将Redis的数据实时迁移至另一套Redis环境,具有一定的参考价值,感兴趣的可以了解一下2023-09-09
这篇文章主要介绍了redis之数据过期清除策略、缓存淘汰策略的用法,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2025-04-04
使用redis-plus-plus库连接redis的实现方法
本文主要介绍了使用redis-plus-plus库连接redis的实现方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2025-02-02
这篇文章主要介绍了antd为Tree组件标题附加操作按钮功能，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下2022-08-08
最新评论