目录
- 1. RDB持久化
- 工作原理
- 触发机制
- 优点
- 缺点
- 配置示例
- 2. AOF持久化
- 工作原理
- 同步策略
- 重写机制
- 优点
- 缺点
- 配置示例
- 3. RDB与AOF比较
- 4. 混合持久化(Redis 4.0+)
- 5. 选择建议
Redis提供了两种主要的持久化机制来保证数据安全：RDB(Redis Database)和AOF(Append Only File)。本帖详细介绍这两种策略的工作原理、优缺点及配置方式。
1. RDB持久化
工作原理
RDB是通过生成数据快照来实现持久化的。它在指定的时间间隔内将内存中的数据集快照写入磁盘，生成一个二进制文件dump.rdb。
触发机制
- 自动触发：通过配置文件设置规则，如
save 900 1表示900秒内至少1个键被修改则触发 - 手动触发：
SAVE命令：阻塞Redis服务器进程直到RDB文件创建完毕
BGSAVE命令：派生(fork)子进程来创建RDB文件，不阻塞服务器
优点
- 性能高：适合大规模数据恢复，对性能影响小
- 紧凑文件：RDB文件是压缩的二进制格式，占用空间小
- 快速恢复：重启时恢复大数据集速度比AOF快
缺点
- 数据丢失风险：最后一次持久化后的数据可能丢失
- fork可能阻塞：数据集大时fork子进程可能耗时较长
配置示例
save 900 1 # 900秒内至少1个key变化
save 300 10 # 300秒内至少10个key变化
save 60 10000 # 60秒内至少10000个key变化
dbfilename dump.rdb
dir /var/lib/redis
2. AOF持久化
工作原理
AOF通过记录每个写操作命令来持久化数据，以日志形式追加到文件中。
同步策略
- appendfsync always：每次写操作都同步，最安全但性能最低
- appendfsync everysec：每秒同步一次(默认)
- appendfsync no：由操作系统决定何时同步
重写机制
为避免AOF文件过大，Redis提供BGREWRITEAOF命令重写AOF文件，去除冗余命令。
优点
- 数据安全性高：最多丢失1秒数据(默认配置)
- 可读性强：AOF文件是文本格式，易于理解和解析
- 自动重写：防止文件过大影响性能
缺点
- 文件体积大：通常比RDB文件大
- 恢复速度慢：执行所有命令恢复数据比RDB慢
- 性能影响：同步策略设置为always时性能下降明显
配置示例
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
3. RDB与AOF比较
| 特性 | RDB | AOF |
|---|---|---|
| 持久化方式 | 定时快照 | 记录每个写操作 |
| 数据安全性 | 可能丢失较多数据 | 最多丢失1秒数据(默认) |
| 恢复速度 | 快 | 慢 |
| 文件大小 | 小(压缩二进制) | 大(文本命令) |
| 性能影响 | 低 | 取决于同步策略 |
| 适用场景 | 大规模数据备份 | 高数据安全性要求 |
4. 混合持久化(Redis 4.0+)
Redis 4.0引入了混合持久化，结合了RDB和AOF的优点：
- AOF文件包含两部分：RDB格式的全量数据 + 增量AOF日志
- 配置方式：
aof-use-rdb-preamble yes
这种模式下，重写后的AOF文件前半段是RDB格式，后半段是增量AOF日志，既保证了恢复速度又减少了数据丢失风险。
5. 选择建议
- 如果允许分钟级数据丢失，优先使用RDB
- 如果需要更高数据安全性，使用AOF
- 如果两者都需要，可以同时启用(重启时AOF优先)
- Redis 4.0+推荐使用混合持久化模式
两种持久化方式可以共存，重启时Redis会优先使用AOF文件来恢复数据，因为AOF通常保存的数据更完整。
