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

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

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：常见故障下可能丢最近约一秒，不是无条件承诺。
• 重写：压缩恢复表示，不保留完整历史审计。
• 运维判断：持久化、复制、备份和恢复演练分别负责不同问题。