Redis 的 RDB 和 AOF 持久化有什么区别？如何选择？

Redis 提供两种持久化机制将内存数据写入磁盘：RDB（快照）和 AOF（追加日志）。理解两者的原理和取舍是后端面试的高频考点，也是生产环境配置的基础。

RDB 持久化：定时快照

RDB 在指定时间间隔内对数据集生成时间点快照，写入压缩的二进制文件 dump.rdb。

触发方式：

• 手动触发：执行 SAVE（阻塞主进程）或 BGSAVE（fork 子进程后台执行）
• 自动触发：配置 save <seconds> <changes> 条件满足时自动执行 BGSAVE
• shutdown 时若开启 RDB 且无 AOF，默认执行 BGSAVE

核心原理 — COW（Copy-On-Write）： BGSAVE 时 Redis 通过 fork() 创建子进程，子进程共享父进程的内存页。当主进程收到写请求，操作系统会将待修改的内存页复制一份，子进程继续在原页面写入 RDB 文件。这就是为什么 RDB 对主进程性能影响小——只有真正被修改的页才会产生额外内存开销。

优点：

1. 文件紧凑：二进制压缩格式，体积远小于 AOF，适合备份和传输
2. 恢复速度快：直接加载二进制文件，比 AOF 重放命令快一个数量级
3. 对主进程影响小：由子进程执行，COW 机制保证主进程正常处理请求
4. 适合冷备份：单文件结构，方便定时拷贝到远程存储

缺点：

1. 数据丢失风险高：两次快照之间的数据变更全部丢失，最坏情况丢失数分钟数据
2. fork 耗时：数据量大时 fork 本身可能阻塞主进程（通常与数据集大小成正比）
3. 无法实时持久化：基于时间间隔，做不到每秒甚至每次写的持久化

关键配置：

conf
save 900 1        # 900秒内至少1个key变化
save 300 10       # 300秒内至少10个key变化
save 60 10000     # 60秒内至少10000个key变化
rdbcompression yes # 压缩RDB文件
rdbchecksum yes   # 文件校验
stop-writes-on-bgsave-error yes # BGSAVE失败时拒绝写入

AOF 持久化：追加日志

AOF 记录每一条写操作命令，以文本格式追加到 appendonly.aof 文件末尾。Redis 重启时逐条重放命令恢复数据。

写入流程：命令追加（append） → 写入缓冲区（aof_buf） → 同步到磁盘（fsync）

同步策略（appendfsync 配置项）：

• always：每次写操作都 fsync，最多丢一条命令，但性能最差
• everysec：每秒 fsync 一次，最多丢 1 秒数据，推荐生产配置
• no：由操作系统决定何时 fsync，性能最好但丢失风险不可控

AOF 重写机制： AOF 文件会持续膨胀。Redis 通过 BGREWRITEAOF 命令在后台重写：fork 子进程遍历当前数据库状态，用最少命令重新生成 AOF 文件。例如对同一 key 执行 100 次 SET，重写后只保留最后一条。重写期间新的写命令同时写入旧 AOF 和重写缓冲区，重写完成后将缓冲区追加到新文件。

优点：

1. 数据安全性高：everysec 策略下最多丢失 1 秒数据
2. 可读可修复：文本格式，可直接查看；误操作后可手动编辑删除错误命令
3. 自动重写压缩：配置阈值触发重写，控制文件体积

缺点：

1. 文件体积大：同等数据量下 AOF 文件通常比 RDB 大数倍
2. 恢复速度慢：逐条重放命令，大规模数据恢复耗时显著
3. 性能开销大：频繁的磁盘 I/O，always 策略下吞吐量明显下降

关键配置：

conf
appendonly yes                  # 开启AOF
appendfsync everysec            # 同步策略
auto-aof-rewrite-percentage 100 # AOF文件大小增长100%时触发重写
auto-aof-rewrite-min-size 64mb  # AOF文件重写的最小大小
aof-load-truncated yes          # 忽略末尾不完整的AOF文件

RDB + AOF 混合持久化

Redis 4.0 引入混合持久化，兼顾两者优势：AOF 重写时将 RDB 格式的全量数据写入 AOF 文件开头，后续增量命令以 AOF 格式追加。

效果：恢复时先快速加载 RDB 部分（快），再重放增量 AOF 命令（完整），数据安全性与恢复速度兼得。

conf
aof-use-rdb-preamble yes  # 开启混合持久化（需同时开启AOF）

恢复优先级：当 RDB 和 AOF 文件同时存在时，Redis 优先加载 AOF，因为 AOF 的数据完整性更高。

面试怎么答：对比速记表

维度	RDB	AOF
原理	定时快照（二进制）	追加写命令（文本日志）
数据安全性	可能丢失数分钟数据	最多丢 1 秒（everysec）
恢复速度	快	慢
文件体积	小	大
性能影响	小（COW）	较大（频繁 I/O）
适用场景	冷备份/灾难恢复	实时持久化/数据安全优先

生产环境选择建议

1. 数据安全优先（金融、支付）：AOF + appendfsync everysec，或混合持久化
2. 性能优先、可容忍少量丢失（缓存场景）：仅 RDB，配置合理的 save 间隔
3. 两者兼顾（通用生产环境）：RDB + AOF 混合持久化，这是 Redis 4.0+ 的推荐方案
4. 纯缓存无需持久化：关闭 RDB 和 AOF，重启后从数据源重新加载

实际生产中，大多数场景采用混合持久化。关闭 RDB 的 save 配置（设为空字符串）可以避免自动触发快照，仅保留 AOF 的实时性，同时定期手动 BGSAVE 做冷备。