Redis 持久化方案对比

Redis 提供了两种主要的持久化方案：RDB（Redis Database Backup） 和 AOF（Append-Only File）。每种方案都有其优缺点，适用于不同的场景。以下是它们的对比及实际操作方案。

---

1. RDB 持久化

1.1 概述

• RDB 是 Redis 默认的持久化方式。
• 它通过生成数据集的快照（snapshot）来保存数据。
• 快照是二进制文件，保存了某个时间点的完整数据。

1.2 优点

• 性能高：RDB 是快照方式，对性能影响较小。
• 文件紧凑：RDB 文件是压缩的二进制文件，占用空间小。
• 恢复速度快：恢复大数据集时比 AOF 更快。

1.3 缺点

• 数据丢失风险：如果 Redis 崩溃，最后一次快照之后的数据会丢失。
• 不适合实时持久化：RDB 是定时快照，无法做到实时持久化。

1.4 配置

在 redis.conf 中配置 RDB：

# 启用 RDB 持久化
save 900 1      # 900 秒内至少有 1 个 key 被修改时触发快照
save 300 10     # 300 秒内至少有 10 个 key 被修改时触发快照
save 60 10000   # 60 秒内至少有 10000 个 key 被修改时触发快照

# RDB 文件名称
dbfilename dump.rdb

# RDB 文件保存路径
dir /var/lib/redis

1.5 手动触发 RDB 快照

可以通过命令手动触发 RDB 快照：

# 在 Redis CLI 中执行
SAVE       # 阻塞主线程，生成快照
BGSAVE     # 后台异步生成快照

---

2. AOF 持久化

2.1 概述

• AOF 通过记录每个写操作（如 SET、DEL 等）来持久化数据。
• 每次写操作都会追加到 AOF 文件的末尾。
• Redis 重启时，通过重放 AOF 文件中的命令来恢复数据。

2.2 优点

• 数据安全性高：AOF 可以配置为每秒同步一次，数据丢失风险低。
• 可读性强：AOF 文件是文本文件，记录了所有写操作，便于分析和修复。

2.3 缺点

• 文件体积大：AOF 文件通常比 RDB 文件大。
• 恢复速度慢：重放 AOF 文件恢复数据时，速度比 RDB 慢。
• 性能开销：频繁写入 AOF 文件可能对性能有一定影响。

2.4 配置

在 redis.conf 中配置 AOF：

# 启用 AOF 持久化
appendonly yes

# AOF 文件名称
appendfilename "appendonly.aof"

# AOF 同步策略
appendfsync everysec  # 每秒同步一次（推荐）
# appendfsync always  # 每次写操作都同步（最安全，但性能差）
# appendfsync no      # 由操作系统决定何时同步（性能最好，但数据安全性低）

# AOF 重写配置
auto-aof-rewrite-percentage 100  # AOF 文件大小增长 100% 时触发重写
auto-aof-rewrite-min-size 64mb   # AOF 文件最小重写大小为 64MB

2.5 手动触发 AOF 重写

AOF 文件会不断增长，可以通过重写来压缩文件：

# 在 Redis CLI 中执行
BGREWRITEAOF  # 后台异步重写 AOF 文件

---

3. RDB 和 AOF 的对比

特性	RDB	AOF
持久化方式	快照	记录每次写操作
文件大小	小	大
数据安全性	可能丢失最后一次快照后的数据	数据丢失风险低
恢复速度	快	慢
性能影响	低	较高
适用场景	数据备份、灾难恢复	高数据安全性要求

---

4. 混合持久化方案

4.1 概述

• Redis 4.0 引入了混合持久化（RDB + AOF）。
• 在 AOF 重写时，将当前数据集的 RDB 快照写入 AOF 文件的开头，后续的写操作仍然以 AOF 格式追加。

4.2 优点

• 快速恢复：重启时先加载 RDB 快照，再重放 AOF 日志，恢复速度快。
• 数据安全：AOF 日志保证了数据的完整性。

4.3 配置

在 redis.conf 中启用混合持久化：

# 启用 AOF
appendonly yes

# 启用混合持久化
aof-use-rdb-preamble yes

---

5. 实际操作方案

5.1 方案 1：仅使用 RDB

• 适用场景：对数据丢失不敏感，需要高性能和快速恢复。
• 配置：

  save 900 1
  save 300 10
  save 60 10000
  appendonly no
  

5.2 方案 2：仅使用 AOF

• 适用场景：对数据安全性要求高，允许一定的性能损失。
• 配置：

  appendonly yes
  appendfsync everysec
  

5.3 方案 3：混合持久化（推荐）

• 适用场景：兼顾数据安全性和恢复速度。
• 配置：

  appendonly yes
  aof-use-rdb-preamble yes
  appendfsync everysec
  

---

6. 数据恢复

6.1 RDB 恢复

• 将 dump.rdb 文件放到 Redis 数据目录（dir 配置项指定的路径）。
• 启动 Redis，数据会自动加载。

6.2 AOF 恢复

• 将 appendonly.aof 文件放到 Redis 数据目录。
• 启动 Redis，数据会自动重放 AOF 文件中的命令。

6.3 混合持久化恢复

• 将 appendonly.aof 文件放到 Redis 数据目录。
• 启动 Redis，Redis 会先加载 RDB 部分，再重放 AOF 部分。

---

7. 总结

• RDB：适合数据备份和快速恢复，但数据丢失风险较高。
• AOF：适合高数据安全性场景，但文件体积大，恢复速度慢。
• 混合持久化：推荐方案，兼顾数据安全性和恢复速度。

根据业务需求选择合适的持久化方案，并合理配置 Redis 以优化性能和数据安全性。