Redis 持久化机制：RDB 和 AOF

Redis 持久化机制：RDB 和 AOF

Redis 主要提供了两种持久化方式：**RDB（Redis Database）**和 AOF（Append-Only File）。它们各自的实现原理、优缺点以及适用场景如下。

---

1. RDB（Redis Database）原理

1.1 RDB 机制

RDB 采用 快照（Snapshotting） 方式定期将 内存中的数据 持久化到磁盘。Redis 会在特定时间点创建数据的二进制快照并存储到 .rdb 文件中。

RDB 触发方式：

• 手动触发：

  • SAVE：同步保存快照，会阻塞 Redis，直到保存完成。
  • BGSAVE：异步保存快照，创建子进程执行快照操作，不影响主进程处理请求。

• 自动触发：

  • 配置 save 规则（默认开启），例如：

    save 900 1  # 900秒（15分钟）内至少有1次写操作
    save 300 10 # 300秒（5分钟）内至少有10次写操作
    save 60 10000 # 60秒（1分钟）内至少有10000次写操作
    

  • 执行 SHUTDOWN 时，若未启用 AOF，则 RDB 触发保存。
  • Redis 复制（Replication）时，主节点自动生成 RDB 发送给从节点进行全量同步。

---

1.2 RDB 工作流程

1. 执行 BGSAVE：

   • Redis **fork（分叉）**一个子进程。
   • 子进程 遍历整个数据集，将其序列化为二进制格式存储到磁盘文件 dump.rdb。
   • 完成后，替换旧的 RDB 文件。

2. RDB 文件格式

   • RDB 文件是二进制格式，存储结构紧凑，便于快速加载。

---

1.3 RDB 优缺点

优点	缺点
适合全量数据备份，占用存储小	可能导致数据丢失（最近一次 RDB 之后的变更未保存）
RDB 结构紧凑，恢复速度快	BGSAVE 需要 fork 进程，内存占用增加
适用于大规模数据冷备	SAVE 操作会阻塞主线程

---

2. AOF（Append-Only File）原理

2.1 AOF 机制

AOF 采用 日志追加（Append-Only Log） 方式，每次执行写操作（SET、HSET、LPUSH 等）时，将命令追加到 .aof 文件。

AOF 触发方式：

• 配置 appendonly yes 开启 AOF 。
• AOF 采用 追加写入，并根据 appendfsync 配置决定何时同步到磁盘：

  appendfsync always   # 每次写操作都 fsync（最安全但影响性能）
  appendfsync everysec # 每秒 fsync 一次（默认，权衡性能和安全）
  appendfsync no       # 交由操作系统决定何时 fsync（最高效但不安全）
  

---

2.2 AOF 工作流程

1. 写入日志：

   • 每次有写操作，Redis 先写入内存 命令日志，然后追加到 AOF 文件。

2. AOF 文件同步（appendfsync）：

   • 根据 appendfsync 策略，将数据刷入磁盘。

3. AOF 重写（Compaction）：

   • 随着时间推移，AOF 文件不断增长，Redis 定期重写（Rewrite） AOF 文件：
   • 触发方式：
     • 手动触发：BGREWRITEAOF
     • 自动触发：Redis 判断 AOF 文件大小增长达到阈值后触发。
   • 重写机制：
     • 创建子进程读取现有数据库状态，并以最少的命令重新写入 AOF。
     • 新文件生成后，替换旧 AOF 文件。

---

2.3 AOF 优缺点

优点	缺点
数据持久性更强，丢失数据少	AOF 文件比 RDB 大，写入速度慢
日志模式可读性好，可用于审计	AOF 恢复速度比 RDB 慢
可自动重写，优化存储	fsync 频率影响性能

---

3. 如何选择 RDB 和 AOF？

3.1 选择 RDB 的场景

✅ 适用于：

• 冷备份场景（如每天凌晨备份）
• 不太关注最近几秒的数据丢失
• 高性能读取（RDB 加载速度快）
• 主从复制初始化（Redis 复制默认使用 RDB）

❌ 不适用于：

• 数据丢失敏感场景
• 频繁写入的大型 Redis 实例（BGSAVE 会占用大量内存）

---

3.2 选择 AOF 的场景

✅ 适用于：

• 数据持久化要求高（如金融、电商系统）
• 实时记录 Redis 变更
• 希望可读的日志文件（如数据审计、问题排查）

❌ 不适用于：

• 对恢复速度要求极高（AOF 启动慢）
• 存储受限的环境（AOF 文件比 RDB 大）

---

3.3 RDB + AOF 组合方案

• 推荐同时开启 RDB 和 AOF：
  • RDB 负责 定期备份，保证快速恢复。
  • AOF 负责 增量持久化，减少数据丢失。

示例配置

# 启用 AOF
appendonly yes
appendfsync everysec# 启用 RDB
save 900 1
save 300 10
save 60 10000

在 Redis 6.0 之后，AOF 支持混合模式（RDB+AOF），减少 AOF 体积：

aof-use-rdb-preamble yes

• 开启后，AOF 先写入 RDB 格式，再记录增量日志。

---

4. 总结对比

对比项	RDB	AOF
存储方式	二进制快照	追加日志
触发方式	定期触发 BGSAVE	实时追加
恢复速度	快	慢（重放日志）
数据丢失风险	最后一次快照后的数据丢失	丢失最近 1s/无丢失（视 appendfsync）
磁盘占用	小	大
写入性能	高	低
适用场景	读密集、全量备份	事务安全、审计、低丢失

---

5. 结论

• 如果数据丢失不可接受，用 AOF。
• 如果恢复速度最重要，用 RDB。
• 如果既要可靠性又要性能，同时开启 RDB 和 AOF，开启 aof-use-rdb-preamble。

这样可以平衡性能、存储和数据安全，让 Redis 运行更稳定。