Redis 从入门到精通：持久化RDB 与 AOF
IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章，助你少走弯路。
Redis 以极致的性能著称，核心原因之一就是所有数据都在内存中读写。但内存的特性是易失的------一旦断电或进程崩溃，所有数据瞬间消失。如果 Redis 只做缓存还好，数据丢了可以从数据库重新加载；可当它承载着分布式锁、计数器、消息队列等关键业务数据时，丢数据就是事故。
因此，Redis 提供了两种持久化机制，将内存数据保存到磁盘：RDB（快照） 和 AOF（追加日志） ，以及它们的结合体------混合持久化。本文带你彻底理解这三种方案的工作原理、配置方法、优缺点和实战策略，让你面对"会不会丢数据"这类问题时从容作答。
1. 为什么需要持久化？
先理清一个概念：持久化不是"备份"，而是数据从内存到磁盘的同步过程。它的价值体现在：
故障恢复：进程崩溃或服务器重启后，能恢复数据，减少损失。
数据迁移：将 RDB/AOF 文件复制到另一台机器，快速恢复整个数据集。
冷备归档：定期保存某一时刻的完整数据快照。
当然，持久化不是免费的------它消耗磁盘 I/O、CPU 和内存，需要在性能 和数据安全之间做权衡。理解每种方案的原理，才能做出正确选择。
2. RDB（Redis Database）------ 内存快照
2.1 什么是 RDB？
RDB 就是在某个时间点 ，把 Redis 中所有数据 生成一份压缩的二进制快照文件 （默认名为 dump.rdb），保存到磁盘。
可以把它理解为：给 Redis 内存拍了一张"照片"，这张照片就是当时全部数据的完整拷贝。
2.2 RDB 的触发方式
① 手动触发
bash
复制代码
# 阻塞主进程，直到保存完成（生产环境禁用）
127.0.0.1:6379> SAVE
OK
# 后台异步保存（推荐）
127.0.0.1:6379> BGSAVE
Background saving started
SAVE：在主进程中执行，保存期间 Redis 不能处理任何命令。数据量大时会严重阻塞，绝对不要在生产环境使用。
BGSAVE：fork 一个子进程，由子进程负责写入 RDB 文件，主进程继续处理请求。这就是我们日常使用的命令。
② 自动触发（配置文件中设置）
打开 redis.conf，你会看到类似这样的配置：
bash
复制代码
# 格式：save
# 含义：在 N 秒内，如果至少有 M 个键被修改，就触发一次 BGSAVE
save 900 1 # 900 秒（15分钟）内，至少 1 个键被修改
save 300 10 # 300 秒（5分钟）内，至少 10 个键被修改
save 60 10000 # 60 秒内，至少 10000 个键被修改
多条规则是或 关系，满足任意一条就触发。也可以清空 save 配置来禁用自动 RDB（但 BGSAVE 手动触发仍有效）。
③ 其他自动触发场景
主从复制时，主节点自动执行 BGSAVE 生成 RDB 文件发给从节点。
执行 SHUTDOWN 关闭 Redis 时，如果没有开启 AOF，会自动执行一次 SAVE。
执行 FLUSHALL 后，如果配置了自动保存规则，会触发一次 RDB（生成空快照，非常危险）。
2.3 RDB 工作原理（BGSAVE 流程）
bash
复制代码
主进程 子进程
│ │
├── fork() ──────────────────> │ (写时复制，共享内存页)
│ │
├── 继续处理客户端命令 ├── 遍历所有数据
│ ├── 写入临时 RDB 文件
│ ├── 完成后，原子重命名为 dump.rdb
│ └── 退出
│ │
└── 子进程结束，主进程继续服务
关键点：fork() 使用了操作系统的**写时复制（Copy-On-Write）**机制。fork 出的子进程和父进程共享同一块物理内存，只有当父进程修改数据时，操作系统才会把对应的内存页复制一份。这样既保证了子进程能看到 fork 瞬间的完整数据，又不会过度占用内存。
⚠️ 如果 fork 后父进程写入量很大，会导致大量内存页被复制，内存占用可能短时间内翻倍。这也是为什么 Redis 需要预留一半内存的原因之一。
2.4 RDB 配置详解
bash
复制代码
# redis.conf
# RDB 文件名
dbfilename dump.rdb
# RDB 文件保存路径（需确保 Redis 有写权限）
dir /data/redis
# 保存规则（前面已介绍）
save 900 1
save 300 10
save 60 10000
# 写入错误时是否停止接受写入（建议 yes）
stop-writes-on-bgsave-error yes
# 是否压缩 RDB 文件（CPU 换磁盘空间）
rdbcompression yes
# 是否对 RDB 文件做完整性校验
rdbchecksum yes
Python 中查看持久化配置：
bash
复制代码
import redis
r = redis.Redis(decode_responses=True)
# 查看 RDB 相关配置
for key in ['dbfilename', 'dir', 'rdbcompression', 'rdbchecksum']:
print(f'{key}: {r.config_get(key)[key]}')
# 手动触发 BGSAVE
result = r.bgsave()
print(f'BGSAVE 是否触发: {result}')
# 查看最近一次 BGSAVE 是否成功（返回 Unix 时间戳）
last_save = r.lastsave()
print(f'上次成功保存时间: {last_save}')
输出示例：
bash
复制代码
dbfilename: dump.rdb
dir: /data
rdbcompression: yes
rdbchecksum: yes
BGSAVE 是否触发: True
上次成功保存时间: 1718092800
2.5 RDB 的优缺点
✅ 优点：
文件紧凑：单一压缩二进制文件，非常适合冷备和灾难恢复。
恢复速度快：直接加载二进制数据到内存，比逐条回放 AOF 快得多。
性能影响小 ：BGSAVE 由子进程完成，主进程只负责 fork，不影响正常请求处理。
适合主从同步：主从复制首次全量同步直接传 RDB 文件。
❌ 缺点：
会丢数据：两次 RDB 之间的数据没来得及持久化，一旦宕机就丢失。
大数据量时 fork 代价高：内存越大，fork 越慢（毫秒到秒级），可能阻塞主进程。
写时复制导致内存压力：频繁写入时，内存占用可能暴涨。
3. AOF（Append Only File）------ 命令日志
3.1 什么是 AOF？
AOF 记录的是每一条修改数据的 Redis 命令 （写入、删除、修改），按时间顺序追加到日志文件中。重启时，Redis 通过逐条回放 AOF 中的命令来重建数据。
可以把它理解为：不是给数据拍照，而是记录下了"拍照后发生的每一条改动"。
3.2 AOF 的开启与基本配置
bash
复制代码
# redis.conf
appendonly yes # 开启 AOF
appendfilename "appendonly.aof" # AOF 文件名
dir /data/redis # 存放目录（与 RDB 共用）
重启 Redis 后，用 redis-cli 观察：
bash
复制代码
127.0.0.1:6379> SET name "IT策士"
OK
127.0.0.1:6379> SET age 30
OK
127.0.0.1:6379> INCR counter
(integer) 1
查看 AOF 文件内容（通过 Docker 进入容器或直接在服务器上）：
bash
复制代码
$ cat /data/appendonly.aof
*3
$3
SET
$4
name
$8
IT策士
*3
$3
SET
$3
age
$2
30
*2
$4
INCR
$7
counter
AOF 文件是 Redis 协议格式的纯文本，可读可解析 。如果误操作 FLUSHALL，还可以手动编辑 AOF 文件删除那条命令然后恢复数据（仅限紧急情况）。
3.3 AOF 写入策略（appendfsync）
Redis 提供三种写入磁盘的策略，由 appendfsync 配置：
bash
复制代码
# 每次写命令都同步到磁盘（最安全，但最慢）
appendfsync always
# 每秒同步一次（默认，性能与安全的最佳平衡）
appendfsync everysec
# 完全依赖操作系统缓冲区刷新（最快，但可能丢大量数据）
appendfsync no
为什么 everysec 是最佳平衡？
Redis 主线程负责将 AOF 写入内存缓冲区，然后由单独的 AOF 刷盘线程 每秒执行一次 fsync 系统调用，将缓冲区数据真正写入磁盘。主线程不参与实际的磁盘写入，所以对性能影响极小。1 秒的数据丢失窗口，对于绝大多数互联网场景是可接受的。
3.4 AOF 重写（Rewrite）------ 防止文件无限膨胀
AOF 会不断追加命令，文件大小必然持续增长。假设一个计数器 INCR 了 100 次，AOF 里会有 100 条 INCR 命令，而实际上恢复数据只需要最后的值。
AOF 重写 就是 Redis 自己创建一个新的 AOF 文件，只包含重建当前数据集所需的最少命令。
bash
复制代码
# 手动触发重写
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
自动重写配置：
bash
复制代码
# 当 AOF 文件体积比上次重写后增长了 100%，且超过 64MB 时，自动触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
重写流程：
bash
复制代码
主进程 子进程
│ │
├── fork() ──────────────────────> │
│ ├── 读取数据库数据
│ ├── 生成新 AOF 文件（最小命令集）
│ └── 退出
├── 期间的新命令同时写入：
│ ├── 旧 AOF 缓冲区（正常 AOF）
│ └── AOF 重写缓冲区（记录增量）
│
└── 子进程完成后，将重写缓冲区的增量写入新 AOF，然后原子替换旧 AOF
这个过程与 RDB 的 BGSAVE 非常类似，利用子进程和写时复制，主进程几乎不受影响。
3.5 AOF 相关配置总览
bash
复制代码
# 开启 AOF
appendonly yes
# 文件路径
appendfilename "appendonly.aof"
# 写入策略
appendfsync everysec
# 重写期间是否继续同步旧 AOF（yes 保证安全但可能阻塞）
no-appendfsync-on-rewrite no
# 自动重写触发条件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# AOF 文件尾部损坏时，是否允许启动（yes 会忽略尾部错误，尝试恢复）
aof-load-truncated yes
3.6 AOF 的优缺点
✅ 优点：
数据更安全 ：everysec 最多丢 1 秒数据，always 完全不丢。
可读性好：AOF 文件是 Redis 协议文本，可直接查看和编辑。
自动重写：防止文件无限增长，保持文件体积可控。
❌ 缺点：
恢复速度慢：重新回放所有命令，大数据量时远比 RDB 慢。
文件体积大：相同数据集，AOF 文件通常比 RDB 大。
写入性能有损耗 ：即使 everysec，每秒刷盘也会消耗 I/O。
4. 混合持久化 ------ Redis 4.0 的最佳方案
既然 RDB 恢复快但可能丢数据，AOF 数据安全但恢复慢，能否鱼与熊掌兼得？Redis 4.0 引入了混合持久化，完美融合了二者的优点。
4.1 混合持久化原理
混合持久化在 AOF 重写时生效。重写出的新 AOF 文件不是纯命令，而是两部分组成：
bash
复制代码
┌─────────────────────────────────────┐
│ RDB 格式的二进制数据 │ ← 重写瞬间的内存快照
│ （占文件前半部分） │
├─────────────────────────────────────┤
│ AOF 格式的增量命令 │ ← 重写过程中新产生的命令
│ （占文件后半部分） │
└─────────────────────────────────────┘
前半部分是 RDB 格式，包含了重写时刻的全部数据，体积小，加载快。
后半部分是 AOF 命令，记录了重写过程中新增的数据修改。
重启加载时，Redis 先读 RDB 部分快速恢复大部分数据，再回放少量 AOF 增量命令，既快又完整。
4.2 开启混合持久化
bash
复制代码
# redis.conf（Redis 4.0+ 支持）
aof-use-rdb-preamble yes
查看并设置：
bash
复制代码
127.0.0.1:6379> CONFIG GET aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "yes"
127.0.0.1:6379> CONFIG SET aof-use-rdb-preamble yes
OK
Python 中检查和触发 AOF 重写：
bash
复制代码
import redis
r = redis.Redis(decode_responses=True)
# 查看混合持久化是否开启
preamble = r.config_get('aof-use-rdb-preamble')['aof-use-rdb-preamble']
print(f'混合持久化: {"开启" if preamble == "yes" else "关闭"}')
# 查看 AOF 信息
info = r.info('persistence')
print(f"AOF 开启: {info['aof_enabled']}")
print(f"AOF 当前大小: {info['aof_current_size']} bytes")
print(f"AOF 基础大小: {info['aof_base_size']} bytes")
# 手动触发 AOF 重写
r.bgrewriteaof()
print("已触发 BGREWRITEAOF")
4.3 混合持久化的优缺点
✅ 优点：
恢复速度快：RDB 部分加载快，附加少量 AOF 回放。
数据完整：AOF 增量保证了重写期间的数据不丢失。
文件体积可控：每次重写生成新文件，比纯 AOF 更小。
❌ 缺点：
可读性降低 ：文件前部分是二进制，不能直接 cat 查看。
兼容性：仅 Redis 4.0+ 支持，老版本无法读取混合格式。
💡 生产推荐 ：同时开启 RDB 和 AOF，开启混合持久化。这是目前最广泛使用也是最稳妥的方案。
5. 备份恢复策略
5.1 数据备份
无论 RDB 还是 AOF，都应该定期将持久化文件备份到其他存储介质（云存储、NAS、异地机器）。
bash
复制代码
# 备份 RDB 文件
cp /data/redis/dump.rdb /backup/redis/dump_$(date +%Y%m%d_%H%M).rdb
# 备份 AOF 文件
cp /data/redis/appendonly.aof /backup/redis/aof_$(date +%Y%m%d_%H%M).aof
Python 自动化备份脚本（配合 crontab 定时执行）：
bash
复制代码
import redis
import shutil
import os
from datetime import datetime
r = redis.Redis(decode_responses=True)
# 1. 触发 BGSAVE，确保 RDB 是最新的
r.bgsave()
# 2. 获取 RDB 文件路径
dir_path = r.config_get('dir')['dir']
rdb_file = r.config_get('dbfilename')['dbfilename']
rdb_path = os.path.join(dir_path, rdb_file)
# 3. 备份到指定目录（加上时间戳）
backup_dir = '/backup/redis'
os.makedirs(backup_dir, exist_ok=True)
timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
backup_path = os.path.join(backup_dir, f'dump_{timestamp}.rdb')
shutil.copy2(rdb_path, backup_path)
print(f'备份完成: {backup_path}')
print(f'文件大小: {os.path.getsize(backup_path)} bytes')
5.2 数据恢复
恢复流程：
停止 Redis。
将备份的持久化文件复制到 Redis 数据目录。
启动 Redis，它会自动加载持久化文件。
bash
复制代码
# 1. 停止 Redis
redis-cli shutdown
# 或 docker stop redis-lab
# 2. 复制备份文件
cp /backup/redis/dump_20260101_0300.rdb /data/redis/dump.rdb
# 3. 重启 Redis
redis-server /etc/redis/redis.conf
# 或 docker start redis-lab
⚠️ 如果同时存在 dump.rdb 和 appendonly.aof，Redis 优先加载 AOF 文件（因为它通常数据更完整）。
5.3 AOF 文件修复
如果 AOF 文件损坏导致 Redis 无法启动：
bash
复制代码
# Redis 自带修复工具
redis-check-aof --fix appendonly.aof
它会截断 AOF 文件到最后一个有效命令处，舍弃尾部损坏部分。
6. 实战：Docker 环境配置持久化
用 Docker 启动一个开启了 RDB + AOF + 混合持久化的 Redis：
bash
复制代码
# 创建本地目录用于挂载
mkdir -p ~/redis-data
# 启动容器
docker run -d \
--name redis-persist \
-p 6379:6379 \
-v ~/redis-data:/data \
redis:7.2 redis-server \
--appendonly yes \
--appendfsync everysec \
--aof-use-rdb-preamble yes \
--save 900 1 \
--save 300 10 \
--save 60 10000
验证：
bash
复制代码
# 进入容器
docker exec -it redis-persist redis-cli
127.0.0.1:6379> CONFIG GET appendonly
1) "appendonly"
2) "yes"
127.0.0.1:6379> CONFIG GET aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "yes"
# 写一些数据
127.0.0.1:6379> SET test "persistence"
OK
# 查看持久化文件
# 在宿主机：ls -lh ~/redis-data/
7. 选型决策树
bash
复制代码
你的 Redis 用途是什么？
│
├── 纯缓存（数据可重建）
│ └── 关掉所有持久化，性能极致
│
├── 一般业务（允许丢 1 分钟数据）
│ └── 只开 RDB，配置 save 规则
│
├── 重要业务（最多丢 1 秒）
│ └── 开 AOF everysec，定期 BGREWRITEAOF
│
└── 核心业务（几乎不能丢数据）
├── RDB + AOF everysec
├── 开启混合持久化
└── 配合主从 + 定期异地备份
8. 动手试试
体验 RDB ：开启 Redis，设置 save 60 1，写入若干键，等待 60 秒观察 dump.rdb 的生成时间和大小。模拟宕机（docker restart），检查数据是否恢复。
体验 AOF 重写 ：循环写入 10 万条 SET，查看 appendonly.aof 文件大小。手动执行 BGREWRITEAOF，对比重写前后的文件大小。
混合持久化对比 ：分别用纯 AOF 和混合持久化方式写入同样的数据，重写后对比文件大小和 redis-benchmark 恢复速度。
模拟恢复：删除 Redis 容器并重新创建，挂载之前的持久化文件，验证数据是否完整恢复。
预期效果：RDB 快照恢复后丢失快照后写入的数据；AOF 恢复完整但慢；混合持久化恢复快且数据完整。
9. 总结
本文我们深入了 Redis 持久化三大方案：
核心要点：
RDB 是"拍照"，AOF 是"录像"，混合是"先拍照再录像"。
everysec 是 AOF 写入策略的甜点。
Redis 4.0+ 一律开启混合持久化。
持久化文件要异地备份，并定期演练恢复。
持久化是 Redis 数据安全的基石。掌握了它，你就懂得了如何在性能和安全之间游刃有余地取舍。下一章，我们将进入 Redis 高可用架构的第一站------主从复制，看如何通过多副本提高数据安全和读吞吐量。
想了解更多还可以去各个平台搜索「IT策士」，一起升级 IT 思维 ！