一、核心概念

RDB（Redis Database）：快照持久化，保存某个时间点的完整数据副本
AOF（Append Only File）：增量持久化，记录每一条写操作命令

两者是 Redis 提供的不同持久化策略，侧重点不同。

二、多维度对比

1. 持久化方式

RDB：全量快照

# 生成 dump.rdb 文件
BGSAVE

# 配置自动触发
save 900 1    # 900秒内至少1个key变化
save 300 10   # 300秒内至少10个key变化
  • 通过 fork() 子进程，采用 COW（写时复制） 机制
  • 将内存中的数据集以二进制格式写入磁盘
  • 生成的 dump.rdb 文件是经过压缩的完整数据快照

AOF：增量日志

# AOF文件内容示例（文本格式）
*3
$3
SET
$4
name
$5
redis

# 对应命令：SET name redis
  • 以文本协议格式记录每个写命令（SET、DEL 等）
  • 不断追加到 appendonly.aof 文件末尾
  • 重启时重新执行 AOF 文件中的命令恢复数据

2. 数据安全性

持久化方式 数据丢失风险 原因
RDB 高（分钟级） 两次快照之间的数据可能丢失
AOF 低（秒级） 根据刷盘策略，最多丢失1秒数据

AOF 刷盘策略：

# appendfsync always      # 每次写操作都刷盘（最安全，最慢）
appendfsync everysec      # 每秒刷盘（推荐，折中方案）
# appendfsync no          # 由OS决定（最快，可能丢失较多数据）

示例场景：

  • 假设配置 save 900 1，Redis 在第 850 秒时宕机
  • RDB：丢失这 850 秒内的所有写入数据
  • AOF（everysec）：最多丢失 1 秒的数据

3. 性能影响

RDB：

  • ✅ 读写性能影响小：异步子进程完成，不阻塞主进程
  • ⚠️ fork() 瞬时影响：数据集大时（几十GB），fork 可能耗时几秒
  • ✅ 磁盘 IO 压力小：间隔触发，频率低

AOF：

  • ⚠️ 持续写入影响：每条写命令都要记录到 AOF 缓冲区
  • ⚠️ 刷盘开销：
    • always：每次都刷盘，严重影响性能
    • everysec：每秒刷盘一次，影响较小
  • ⚠️ 重写开销：AOF 文件过大时触发重写（类似 RDB 的 fork）

性能测试参考：

纯内存操作：      100,000 ops/s
RDB（后台）：     95,000 ops/s   （影响约5%）
AOF（everysec）： 80,000 ops/s   （影响约20%）
AOF（always）：   30,000 ops/s   （影响约70%）

4. 文件大小

RDB：

  • 压缩后的二进制文件，体积小
  • 典型场景：1GB 内存数据 → 200-300MB RDB 文件

AOF：

  • 文本格式，可读但体积大
  • 未重写时会不断增长
  • 典型场景：1GB 内存数据 → 可能生成几GB 的 AOF 文件

AOF 重写机制：

# 当AOF文件大小是上次重写后的100%时，且文件大于64MB，触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

重写后，AOF 文件会大幅缩小，接近 RDB 的大小。

5. 恢复速度

RDB：快

  • 直接加载二进制数据到内存
  • 大数据集场景下优势明显
  • 恢复时间：GB级数据通常在分钟级别

AOF：慢

  • 需要重新执行每一条命令
  • 数据量大时恢复时间长
  • 恢复时间：GB级数据可能需要几十分钟甚至更久

6. 数据完整性与可读性

RDB：

  • ❌ 二进制格式，不可读
  • ❌ 文件损坏时难以修复
  • ✅ 数据一致性强（某个时间点的完整快照）

AOF：

  • ✅ 文本格式，可读可修改
  • ✅ 文件损坏时可以手动修复（redis-check-aof --fix）
  • ⚠️ 如果记录了错误命令，恢复时会重新执行错误

7. 适用场景

场景 推荐方案 原因
数据备份 RDB 文件小，便于传输和存储
主从全量复制 RDB 传输快，恢复快
对数据完整性要求高 AOF 最多丢失1秒数据
可容忍分钟级数据丢失 RDB 性能更好
生产环境 RDB + AOF 结合两者优点
高并发写入 RDB AOF 写入压力大

三、混合使用策略

1. 同时开启 RDB 和 AOF 

# 开启AOF
appendonly yes
appendfsync everysec

# 开启RDB
save 900 1
save 300 10
save 60 10000

# 开启混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes

恢复优先级：

  • Redis 重启时，如果 AOF 文件存在，优先使用 AOF 恢复数据
  • AOF 文件不存在或损坏时，才使用 RDB 文件

2. 混合持久化（Redis 4.0+） 

AOF 文件结构：
┌─────────────────────┐
│  RDB 格式的快照数据  │  ← 重写时刻的完整数据（二进制）
├─────────────────────┤
│  AOF 格式的增量命令  │  ← 重写后的新增命令（文本）
└─────────────────────┘

优势：

  • 结合 RDB 的快速恢复和 AOF 的数据完整性
  • 恢复时，先加载 RDB 部分，再执行 AOF 部分

四、对比总结表

维度 RDB AOF
持久化方式 全量快照 增量命令日志
文件格式 二进制（压缩） 文本（协议格式）
文件大小 小 大（重写后接近RDB）
数据安全性 低（可能丢失分钟级数据） 高（最多丢失1秒数据）
恢复速度 快 慢
性能影响 小 中
可读性 不可读 可读
修复能力 难 易（redis-check-aof）
适用场景 备份、主从复制 数据完整性要求高

五、面试答题模板

简洁版：

RDB 是全量快照，定期保存完整数据，文件小、恢复快，但可能丢失几分钟数据；AOF 是增量日志，记录每条写命令，数据完整性高（最多丢1秒），但文件大、恢复慢。生产环境推荐两者结合使用，Redis 重启时优先用 AOF 恢复。

详细版：

  1. 持久化方式：RDB 是二进制快照，AOF 是文本命令日志
  2. 数据安全：RDB 可能丢失几分钟数据，AOF 根据刷盘策略最多丢1秒
  3. 性能：RDB 对性能影响小，AOF 需要持续写入，有一定开销
  4. 恢复速度：RDB 快（直接加载），AOF 慢（重新执行命令）
  5. 文件大小：RDB 小（压缩），AOF 大（需定期重写）
  6. 生产建议：开启混合持久化（Redis 4.0+），兼顾恢复速度和数据安全