Redis 持久化机制深度解析（RDB / AOF / 混合持久化）
作者：心之伊始
适合读者：后端工程师 / 架构师 / 对 Redis 稳定性与数据安全有要求的技术人员
一、为什么 Redis 需要持久化？
Redis 是内存数据库，其核心优势是：
- 极致的读写性能（QPS 可达百万级）
- 简单高效的数据结构
但内存有一个致命问题：
进程一旦退出，数据全部丢失
典型异常场景包括：
- Redis 进程 crash
- 服务器宕机 / 掉电
- 容器重启 / Pod 重建
- 人为误操作（kill -9）
持久化的目标：
在性能、数据安全、恢复速度之间找到平衡点。
二、Redis 持久化的整体设计
Redis 提供了三种持久化方案：
| 方案 | 全称 | 核心思想 |
|---|---|---|
| RDB | Redis DataBase | 定期生成内存快照 |
| AOF | Append Only File | 记录每一条写命令 |
| 混合持久化 | RDB + AOF | 启动时用 RDB，运行时用 AOF |
整体架构示意
┌──────────────┐
│ Client │
└──────┬───────┘
│ write
▼
┌──────────────┐
│ Redis │
│ (Memory) │
└───┬────┬─────┘
│ │
RDB 快照│ │AOF 日志
▼ ▼
dump.rdb appendonly.aof三、RDB 持久化：内存快照机制
3.1 RDB 是什么？
RDB 是 某一时刻 Redis 内存数据的全量快照 ，生成一个 dump.rdb 文件。
一句话理解：
给 Redis 的内存拍一张"全家福"。
3.2 RDB 触发方式
1️⃣ 手动触发
bash
SAVE # 同步阻塞（不推荐）
BGSAVE # 异步（推荐）2️⃣ 自动触发（最常用）
conf
save 900 1 # 900 秒内有 1 次写
save 300 10
save 60 100003️⃣ 主从复制触发
- slave 第一次全量同步
- 会触发主节点 BGSAVE
3.3 RDB 的底层实现（重点）
BGSAVE 的核心流程
主进程 (Redis)
│
├─ fork() ──────────────┐
│ │
父进程 子进程
继续处理请求 遍历内存数据
↓
生成 dump.rdb关键技术点：Copy-On-Write（COW）
-
fork 后父子进程共享内存页
-
只有当父进程发生写操作时：
- 操作系统才会复制对应内存页
优点：
- 不阻塞 Redis 主线程
- 最大化复用内存
隐患：
- 写入密集场景下，内存瞬间翻倍
3.4 RDB 的优缺点
✅ 优点
-
文件紧凑，恢复速度极快
-
非常适合：
- 冷备份
- 全量恢复
- 主从复制
❌ 缺点
- 数据可能丢失（分钟级）
- fork + COW 对内存压力大
四、AOF 持久化：操作日志机制
4.1 AOF 是什么？
AOF 以日志的形式记录所有写命令：
SET user:1 Tom
INCR order_id
DEL cache:keyRedis 重启时：
重新"回放"这些命令，恢复数据。
4.2 AOF 写入流程（非常重要）
Client write
│
▼
Redis 执行命令
│
▼
写入 AOF 缓冲区
│
▼
根据策略刷盘4.3 AOF 刷盘策略
conf
appendonly yes
appendfsync always| 策略 | 行为 | 数据安全 | 性能 |
|---|---|---|---|
| always | 每条命令 fsync | ★★★★★ | ★ |
| everysec（默认） | 每秒 fsync | ★★★★ | ★★★★ |
| no | OS 控制 | ★ | ★★★★★ |
👉 生产环境推荐：everysec
4.4 AOF 重写（Rewrite）机制
问题：
AOF 文件会无限增长：
INCR a
INCR a
INCR a
...解决方案：AOF Rewrite
INCR a (10000 次)
↓
SET a 10000重写流程
主进程 fork 子进程
│
├─ 子进程生成新 AOF（基于内存）
│
├─ 主进程写入 rewrite buffer
│
▼
合并 rewrite buffer
替换旧 AOF 文件⚠️ 整个过程无阻塞主线程
4.5 AOF 的优缺点
✅ 优点
- 数据更安全（秒级）
- 可读性强（文本命令）
❌ 缺点
- 文件体积大
- 恢复速度慢
五、混合持久化（Redis 4.0+）
5.1 混合持久化是什么？
AOF Rewrite 时：前半段是 RDB，后半段是 AOF
conf
aof-use-rdb-preamble yes5.2 文件结构示意
| RDB Snapshot | AOF Increment Commands |5.3 优势
- 启动速度接近 RDB
- 数据安全性接近 AOF
👉 目前生产环境的最优解
六、生产环境选型建议（经验总结）
| 场景 | 推荐方案 |
|---|---|
| 缓存型数据 | RDB |
| 金融 / 订单 | AOF everysec + 混合 |
| 大内存实例 | 混合持久化 |
| 高写入 | 避免频繁 BGSAVE |
推荐配置模板
conf
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 900 1
save 300 10
save 60 10000七、Java 技术专家视角的几个常见误区
❌ 误区 1：Redis 开了持久化就不会丢数据
→ everysec 仍然可能丢 1 秒
❌ 误区 2：RDB 对性能没影响
→ fork + COW 是隐形炸弹
❌ 误区 3：AOF 一定比 RDB 安全
→ no fsync ≈ 不持久化
八、总结一句话
Redis 持久化，本质是：在性能、数据安全、恢复速度之间做工程权衡。