RDB和AOF的写回策略分别是什么？

https://chat.deepseek.com/share/fde8hr0ntim25od7w9

面试记录 2026-10-15

题目：RDB和AOF的写回策略分别是什么？

难度：low

评分：⭐⭐⭐⭐☆☆☆（2/5）

我的回答

RDB 是一次性把整个的快照直接加载到内存中，一次性直接就完成了。而 AOF 本身存储的是大量的命令，它需要逐个去执行才能完成整个写回。所以在备份的时候，RDB 加载的会更快，AOF 在执行时间长了加载的会更慢。这个原因，Redis 后期推出了混合的策略。历史的数据使用 RDB，最新的数据使用 AOF，后续的逐步的进行替换，把 AOF 内容放到 RDB 中。RDB 来实现远期数据的存储，AOF 实行实时短期的几秒内数据的展现，这样可以更快的加载，也更全面的加载，保证系统的数据稳定性、系统数据安全。

点评

优点：

RDB/AOF 加载速度差异抓到了- Redis 4.0 混合持久化提到

不足：

❌ 答非所问：题目问写回策略(fsync)，答成了加载策略- ❌ 遗漏 fsync.always / fsync.everysec / no 三种策略- ❌ 遗漏 appendfsync 参数- ❌ 遗漏 RDB fork + COW 子进程机制- ❌ 遗漏 AOF rewrite (bgrewriteaof)

完整讲解

第一部分：知识重点剖析

核心考点：考察对 Redis 持久化写回策略（fsync）的理解，区分"写回"和"加载"两个不同方向。

知识点拆解：

1. RDB 写回策略：RDB 是快照，fork 子进程 + COW 机制。触发时机：手动（SAVE/BGSAVE）、配置（save 60 10000 / save 300 1000 / save 900 1）、子进程完成后原子替换。
2. AOF 写回策略（appendfsync）：

• always：每条命令立即 fsync 到磁盘，最安全但性能最低（QPS 降到几百）
• everysec（默认）：每秒 fsync 一次，性能和安全折中，最多丢 1 秒数据
• no：由 OS 决定何时 fsync（通常 30 秒），性能最高但可能丢大量数据

1. AOF rewrite：AOF 文件过大时，BGREWRITEAOF 触发，fork 子进程重写压缩 AOF。
2. 混合持久化（Redis 4.0+）：AOF rewrite 时前半段用 RDB 格式（历史数据），后半段用 AOF 格式（rewrite 期间的增量），兼顾启动速度和数据安全性。

关键参数：

• appendfsync（always/everysec/no）
• auto-aof-rewrite-percentage（默认 100）
• auto-aof-rewrite-min-size（默认 64MB）

第二部分：考察方向与延伸递进

1. RDB 和 AOF 同时开启，恢复优先级？

• 解答：默认优先 AOF，因为 AOF 数据更完整。可通过 aof-use-rdb-preamble 调整。

1. AOF 文件过大怎么办？

• 解答：BGREWRITEAOF 自动触发（达到阈值时），或手动执行。rewrite 期间新命令写入临时 AOF，完成后合并。

1. fsync.always 为什么生产不用？

• 解答：每次命令都要 fsync 到磁盘，QPS 降到几百，性能损失巨大。生产一般用 everysec，最多丢 1 秒数据。

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，Redis 写回策略主要是 AOF 的 appendfsync 参数，分三档：always、everysec、no。

always 是每条命令立即 fsync 到磁盘，最安全但性能最低，QPS 降到几百，生产一般不用。

everysec 是默认值，每秒 fsync 一次，性能和安全性折中，最多丢 1 秒数据。生产环境推荐这个。

no 是让 OS 决定何时 fsync（通常 30 秒），性能最高但可能丢大量数据，一般不用。

RDB 是快照，fork 子进程 + COW 机制，触发时机是手动 SAVE/BGSAVE 或配置（save 60 10000 等）。RDB 写回后原子替换旧文件。

Redis 4.0 引入了混合持久化，AOF rewrite 时前半段用 RDB 格式存历史数据，后半段用 AOF 格式存增量，兼顾启动速度和数据安全性。

参数方面，appendfsync 控制 AOF 写回频率，auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 控制 AOF rewrite 触发阈值。