Redis 两种数据持久化方式对比

Redis 提供 RDB（快照） 和 AOF（追加文件） 两种持久化方式，其核心差异在于 数据安全性、性能开销、恢复速度 等维度。以下是深度对比与场景建议：

---

一、核心机制对比

维度	RDB	AOF
持久化原理	定时内存快照（二进制压缩）	记录所有写命令（文本追加）
数据完整性	可能丢失最后一次快照后的数据	可配置为秒级/实时持久化（fsync）
文件体积	小（压缩二进制）	大（需定期重写优化）
恢复速度	极快（直接加载内存）	慢（需逐条重放命令）
写开销	低（fork子进程）	高（主线程追加命令，后台fsync）
容灾能力	单文件易备份	AOF文件破损可通过 redis-check-aof 修复

---

二、持久化策略与配置

RDB 核心配置

save 900 1       # 900秒内至少1次修改触发快照
save 300 10      # 300秒内至少10次修改触发
dbfilename dump.rdb
stop-writes-on-bgsave-error yes  # 快照失败时拒绝写入

AOF 核心配置

appendonly yes
appendfsync everysec  # 折衷方案：每秒fsync（推荐）
# appendfsync always  # 每次写都fsync（安全但慢）
# appendfsync no      # 由操作系统决定（风险高）
auto-aof-rewrite-percentage 100  # AOF文件增长100%时重写
auto-aof-rewrite-min-size 64mb   # AOF重写最小阈值

---

三、生产环境性能影响

1. RDB 的阻塞风险

• fork 延迟：
  内存越大，fork 子进程耗时越长（10GB 内存 fork 约 100ms）
  → 可通过 repl-backlog-size 缓解主从同步中断
• 磁盘 I/O 峰值：
  快照时产生大量磁盘写入（建议用 SSD）

2. AOF 的潜在问题

• 重写期间内存翻倍：
  AOF 重写需内存快照，可能触发 OOM（控制 auto-aof-rewrite-percentage）
• fsync 延迟抖动：
  always 模式在高并发下导致 TPS 下降 90%（改用 everysec）

---

四、灾难恢复能力对比

故障场景	RDB	AOF
Redis 进程崩溃	丢失最后一次快照后的数据	丢失最后一次 fsync 后的数据
服务器断电	可能损坏 RDB 文件（需校验）	AOF 尾部命令丢失但可修复
误删数据	无法恢复（快照已覆盖）	回放 AOF 至删除前的最后状态

💡 最佳实践：
启用混合持久化（Redis 4.0+）

aof-use-rdb-preamble yes  # AOF重写时首段用RDB格式，恢复速度提升90%

---

五、选型决策矩阵

场景	推荐方案	理由
缓存服务（允许丢数据）	RDB	恢复快，资源占用低
金融交易（零数据丢失）	AOF（appendfsync always）	数据安全优先
高并发写入	RDB + AOF（everysec）	平衡性能与安全
内存 > 32GB	AOF	避免 fork 阻塞风险

---

六、运维操作命令

1. 手动触发快照：

   SAVE          # 阻塞主线程（生产禁用）
   BGSAVE        # 后台异步执行（推荐）
   

2. AOF 重写：

   BGREWRITEAOF  # 后台重写AOF文件
   

3. 恢复流程：
   • 关闭 Redis → 将备份文件（dump.rdb 或 appendonly.aof）放入目录 → 重启 Redis

---

七、混合持久化（RDB+AOF）运作流程

graph TB
A[写入命令] --> B[实时写入AOF缓冲区]
B --> C[根据策略fsync到磁盘]
C --> D{AOF文件过大？}
D -->|是| E[触发AOF重写]
E --> F[子进程生成RDB快照]
F --> G[将快照后的增量命令转为AOF]
G --> H[新AOF = RDB头 + 增量AOF]

优势：

• 重启加载时 优先读取RDB部分（秒级恢复），再重放增量AOF命令
• 数据安全性 = AOF，恢复速度 ≈ RDB

---

终极建议

1. 生产标配：

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

2. 监控指标：

   • rdb_last_bgsave_status：上次快照状态
   • aof_last_bgrewrite_status：AOF重写状态
   • aof_delayed_fsync：因fsync阻塞的写操作

3. 备份策略：

   • 每小时 RDB 快照 + 每日异地备份
   • 启用 no-appendfsync-on-rewrite yes 避免重写时 fsync 阻塞

通过合理配置，Redis 持久化可兼顾 性能、安全与运维效率，混合模式是当前最优解。