Redis 的 RDB 和 AOF 有什么区别？宕机后哪些数据可能丢失？

🧑‍💻 面试官：Redis 开了持久化，收到 OK 的写入就一定不会丢吗？

🙋‍♂️ 我：还要看持久化方式和落盘策略，回复成功不一定表示已经同步到磁盘。

🧑‍💻 面试官：RDB 和 AOF，分别保存的是什么？

🙋‍♂️ 我：RDB 保存某个时点的数据快照，AOF 记录用于恢复数据的写入操作。

🧑‍💻 面试官：AOF 每秒同步一次，就能承诺任何故障都最多丢一秒吗？如果磁盘根本不可用呢？

先顺着「执行、写入缓冲、同步落盘」看数据到了哪里，再判断某种故障下能恢复多少。

面试速答（60 秒版）

RDB 保存某个时点的数据快照，文件较紧凑，恢复时直接加载快照，但快照完成以后发生的写入，单靠这份 RDB 无法找回。

AOF 记录用于重建数据的写入操作。数据能保留到什么程度，还取决于同步策略：每次同步更强调持久性，每秒同步在常见故障下可能损失最近约一秒，交给操作系统同步则没有同样的时间承诺。

但这些都依赖磁盘、系统与错误处理正常，不能把配置名称当成任何故障下的绝对保证。现代 Redis 的 AOF 还可能包含基础文件和增量文件，重写也不等于把所有历史命令永久保存。

实际选择要先明确允许丢多少、恢复多久，并做真实恢复测试。持久化也不等于备份，误删数据后被正常记录，仍需要独立备份找回。

这里假设故障发生在后两次写入尚未同步时，用来对比恢复范围；时间刻度不代表实际 fsync 周期。

知识点详解：收到写入成功以后，数据还有哪几步？

RDB 留下的是一个时点

假设 Redis 在 10:00 完成了一份快照，之后写入了一批新订单状态，10:03 机器故障。

如果只能加载 10:00 的 RDB，就只能恢复这份快照包含的数据。后面的写入并不会因为客户端收到过 OK，就自动出现在文件里。

后台生成 RDB 通常会涉及子进程和写时复制。它减少了长时间阻塞主进程的需要，但 fork、页表和写入期间的内存复制仍可能带来资源压力。不能说后台保存完全没有性能影响。

具体可恢复的时点，取决于成功生成并保存了哪份文件，而不是配置写着每隔多久尝试一次。

AOF 为什么还要讨论 fsync？

数据修改以后，AOF 内容可能先进入程序或操作系统缓冲，再由同步操作推进到持久存储。

写入文件成功和已经可靠同步到磁盘，是不同阶段。进程崩溃、操作系统崩溃和机器断电，也不是完全相同的故障。

appendfsync always 更积极地同步写入，通常付出更高写入成本；everysec 通常由后台周期同步；no 则依赖操作系统安排。应用收到回复时的数据位置，需要结合实际同步策略理解。Redis 持久化官方说明介绍了这些选项。

“每秒同步可能丢约一秒”是常见健康运行条件下的说明，不能承诺磁盘损坏、I/O 长时间卡住或持久化错误时也一定满足这个窗口。

AOF 重写是不是把日志清空？

不是。长时间记录会使恢复文件变大，因此重写根据当前状态生成更紧凑的恢复表示，同时处理重写期间的新写入。

例如，一个 key 被修改很多次，恢复当前状态并不需要重放全部历史变化。重写后的内容可以只保留重建当前数据所需的操作。

现代 Redis 的多部分 AOF 可以使用基础文件、增量文件及清单，基础部分也可能采用 RDB 格式。它不是一份永远只追加、永远包含全部操作历史的审计账本。

因此，备份时需要取得完整且一致的恢复文件集合，不能随手复制一个看起来最新的文件就结束。

两种方式一起开，就一定不会丢数据吗？

也不能这样保证。RDB 与 AOF 可以提供不同的恢复与运维选择，但它们仍共享一些故障风险，例如同一磁盘损坏。

复制同样不能替代持久化和备份。副本可能还没收到最新写入，误删除也可能被复制过去。

选择时先确定恢复点目标，也就是允许失去多新的数据；再确定恢复时间目标，也就是恢复到可服务状态允许多久。这两个要求会影响同步策略、备份和部署方式。

面试官继续追问

开了 AOF，就不用 RDB 了吗？

不一定。RDB 便于保存某个时点的副本，适合备份与迁移等场景；AOF 提供另一种写入恢复方式。

是否同时启用，要结合资源与恢复需求。不能为了功能全开而忽略重写、快照和备份同时运行的峰值开销。

缓存数据都可以从数据库重建，还需要持久化吗？

可以不采用同样的持久化要求，但要考虑重启后的回源压力和重建时间。

如果 Redis 保存的是无法从其他地方重建的业务状态，要求就不同。先分清哪些是缓存、哪些是权威数据，不能对所有 key 使用同一句建议。

怎样做一次有效的恢复演练？

在隔离测试环境使用可核对的写入序列，测试相应故障和恢复方式，确认恢复到了哪个编号、花了多久。

还要检查文件集合、权限、容量和备份可用性。只确认 Redis 重启成功，不代表数据完整，更不代表备份真的能恢复。

面试速记卡

• RDB：保存成功快照中的状态，之后的写入不在这份文件中。

• AOF：保存恢复操作，持久性依赖写入与同步策略。

• everysec：常见故障下可能丢最近约一秒，不是无条件承诺。

• 重写：压缩恢复表示，不保留完整历史审计。

• 运维判断：持久化、复制、备份和恢复演练分别负责不同问题。