Redis持久化策略：RDB与AOF详解

Redis提供了两种主要的持久化机制来保证数据安全：RDB(Redis Database)和AOF(Append Only File)。本帖详细介绍这两种策略的工作原理、优缺点及配置方式。

1. RDB持久化

工作原理

RDB是通过生成数据快照来实现持久化的。它在指定的时间间隔内将内存中的数据集快照写入磁盘，生成一个二进制文件dump.rdb。

触发机制

1. 自动触发：通过配置文件设置规则，如save 900 1表示900秒内至少1个键被修改则触发
2. 手动触发：
   SAVE命令：阻塞Redis服务器进程直到RDB文件创建完毕
   BGSAVE命令：派生(fork)子进程来创建RDB文件，不阻塞服务器

优点

1. 性能高：适合大规模数据恢复，对性能影响小
2. 紧凑文件：RDB文件是压缩的二进制格式，占用空间小
3. 快速恢复：重启时恢复大数据集速度比AOF快

缺点

1. 数据丢失风险：最后一次持久化后的数据可能丢失
2. 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. 数据安全性高：最多丢失1秒数据(默认配置)
2. 可读性强：AOF文件是文本格式，易于理解和解析
3. 自动重写：防止文件过大影响性能

缺点

1. 文件体积大：通常比RDB文件大
2. 恢复速度慢：执行所有命令恢复数据比RDB慢
3. 性能影响：同步策略设置为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通常保存的数据更完整。