Redis RDB和AOF 流程、优缺点详细介绍

Redis 提供了两种主要的持久化方式：RDB（Redis Database） 和 AOF（Append Only File）。它们的设计目标、实现机制以及适用场景各不相同。以下是它们的详细工作流程和特点：

---

一、RDB（快照持久化）

原理：通过生成某个时间点的数据快照（二进制文件）保存到磁盘，默认文件名为 dump.rdb。

触发方式

1. 手动触发：
   • 执行 SAVE 命令：阻塞主线程，直到快照生成完成（生产环境慎用）。
   • 执行 BGSAVE 命令（推荐）：fork 子进程异步生成快照，主线程继续处理请求。
2. 自动触发：
   • 配置 save <seconds> <changes>：例如 save 900 1 表示 900 秒内至少 1 次修改时触发 BGSAVE。
   • 主从复制时，从节点首次同步会触发 BGSAVE。
   • 执行 SHUTDOWN 或 FLUSHALL 时自动触发（除非配置禁止）。

详细过程

1. BGSAVE 流程：
   • Redis 主进程 fork 一个子进程（使用 Copy-On-Write 机制）。
   • 子进程遍历内存数据，写入临时 RDB 文件。
   • 完成时替换旧的 RDB 文件（原子操作）。
   • 子进程退出并通知主进程。
2. RDB 文件内容：
   • 二进制格式，包含键值对、过期时间等元数据。
   • 紧凑且压缩，适合备份和灾难恢复。

优缺点

• 优点：
  • 文件小，恢复速度快。
  • 适合备份和全量复制场景。
• 缺点：
  • 可能丢失最后一次快照后的数据（取决于触发间隔）。
  • 大数据量时 fork 可能阻塞主线程（内存越大阻塞时间越长）。

---

二、AOF（日志追加持久化）

原理：记录所有写操作命令（文本格式），通过重放日志恢复数据。

触发方式

1. 实时写入：
   • 每个写命令追加到 AOF 缓冲区，根据配置同步到磁盘：
     • appendfsync always：每次写命令都同步（安全但性能差）。
     • appendfsync everysec（默认）：每秒同步一次（平衡性能与安全）。
     • appendfsync no：由操作系统决定（可能丢失较多数据）。
2. AOF 重写（Rewrite）：
   • 解决 AOF 文件膨胀问题，生成紧凑的新 AOF 文件（仅保留最终数据状态的命令）。
   • 触发条件：
     • 手动执行 BGREWRITEAOF。
     • 自动触发（auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 64MB）。

详细过程

1. AOF 写入流程：
   • 命令执行 → 写入 AOF 缓冲区 → 根据 appendfsync 策略同步到磁盘。
2. AOF 重写流程：
   • fork 子进程，扫描内存数据生成新 AOF 临时文件。
   • 期间的新写操作同时写入原 AOF 缓冲区和重写缓冲区。
   • 子进程完成后，将重写缓冲区的数据追加到新 AOF 文件。
   • 原子替换旧 AOF 文件。

优缺点

• 优点：
  • 数据安全性高（可配置为秒级同步）。
  • 可读性强（文本格式），支持手动修复。
• 缺点：
  • 文件体积较大（需定期重写）。
  • 恢复速度慢于 RDB（尤其大文件时）。

---

三、混合持久化（Redis 4.0+）

原理：结合 RDB 和 AOF，在 AOF 文件中嵌入 RDB 格式的快照数据。

• 触发条件：开启 aof-use-rdb-preamble yes 后，AOF 重写时先写入 RDB 快照，再追加增量 AOF 日志。
• 优点：恢复时先加载 RDB 快照，再重放增量日志，兼顾速度与安全性。

---

四、如何选择？

• RDB：适合允许分钟级数据丢失、需要快速恢复或备份的场景。
• AOF：适合对数据安全性要求高、能容忍较大文件的场景。
• 混合模式：推荐在 Redis 4.0+ 中使用，平衡性能和数据安全。

---

五、配置示例

# RDB 配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis

# AOF 配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-use-rdb-preamble yes

通过理解这两种机制的差异，可以根据业务需求选择合适的持久化策略。