Redis 持久化机制：RDB 与 AOF 的深入对比

Redis 作为内存数据库，进程退出后数据就会丢失。持久化是保证数据安全的核心能力。Redis 提供了两种持久化方式：RDB（快照） 和 AOF（追加日志）。

在我的项目中，Redis 同时承担了缓存、分布式锁和会话存储的角色，选择合适的持久化策略直接影响数据安全性和性能。

RDB（Redis Database）

原理

RDB 通过生成某个时间点的全量数据快照来实现持久化。Redis fork 一个子进程，子进程遍历内存数据写入临时文件，完成后原子替换旧文件。

1
2
3
4
5
6
7
8

主进程                      子进程
  │                           │
  ├── fork() ────────────────>│
  │                           ├── 遍历内存数据
  │   继续处理客户端请求        ├── 写入临时 rdb 文件
  │                           ├── 替换旧 rdb 文件
  │                           └── 退出

fork 使用操作系统的 Copy-on-Write 机制：子进程与父进程共享内存页，只有当父进程修改某页数据时才会复制该页。因此 fork 本身很快，但如果在快照期间有大量写入，内存占用会显著上升。

触发方式

1
2
3
4
5
6
7
8
# 手动触发
SAVE       # 同步阻塞，生产环境禁用
BGSAVE     # 异步 fork 子进程

# 自动触发（redis.conf）
save 900 1      # 900 秒内至少 1 次修改
save 300 10     # 300 秒内至少 10 次修改
save 60 10000   # 60 秒内至少 10000 次修改

优缺点

✅ 优点	❌ 缺点
文件紧凑，适合备份和灾难恢复	两次快照之间的数据可能丢失
恢复速度快（直接加载二进制）	数据量大时 fork 耗时较长
对主线程影响小	fork 瞬间内存可能翻倍（COW）

AOF（Append Only File）

原理

AOF 记录每一条写命令，追加到文件末尾。重启时重放所有命令来恢复数据。

同步策略

1
2
3
appendfsync always    # 每条命令都同步，最安全，性能最差
appendfsync everysec  # 每秒同步（推荐，最多丢 1 秒数据）
appendfsync no        # 由 OS 决定，性能最好，可靠性最差

AOF 重写

AOF 文件会不断膨胀，Redis 通过重写机制压缩文件体积：

1
2
3
4
5
6

原始 AOF:              重写后:
SET counter 1          SET counter 4
INCR counter           ← 等效合并
INCR counter
INCR counter

重写同样通过 fork 子进程执行，不阻塞主线程。

优缺点

✅ 优点	❌ 缺点
数据安全性高（最多丢 1 秒）	文件体积通常比 RDB 大
可读性好，便于分析和调试	恢复速度慢（重放命令）
重写机制控制文件大小	持续写入有 I/O 压力

对比总结

维度	RDB	AOF
数据安全	可能丢失分钟级数据	最多丢失 1 秒
文件大小	小（二进制压缩）	大（文本命令）
恢复速度	快	慢
性能影响	fork 时短暂影响	持续写入
适用场景	定期备份、容灾	数据安全要求高

生产环境推荐：混合持久化

Redis 4.0+ 支持 RDB + AOF 混合持久化：

1
aof-use-rdb-preamble yes

重写时先以 RDB 格式写入全量数据，再追加增量 AOF 命令。兼顾恢复速度和数据安全。

追求性能用 RDB，追求安全用 AOF，生产环境开混合持久化。