Redis 的 RDB 和 AOF 持久化有什么区别？

简化版

RDB 是按时间点生成内存快照，恢复快、文件紧凑，但两次快照之间宕机会丢数据；AOF 是追加写命令日志，数据安全性更高，但文件更大、恢复可能更慢。生产上常见做法是 RDB + AOF 混合使用，用 RDB 提供快速基线，用 AOF 降低数据丢失窗口。

详细版

RDB 和 AOF 的区别：

维度	RDB	AOF
记录内容	某一时刻的数据快照	写命令追加日志
文件大小	通常较小	通常较大，需要 rewrite
恢复速度	较快	取决于日志大小
数据安全	可能丢失最近一次快照后的数据	取决于 fsync 策略，通常更安全
适用场景	备份、全量恢复、快速重启	更关注数据丢失窗口的场景

AOF 的 appendfsync 常见策略有：

• always：每次写都刷盘，最安全但最慢；
• everysec：每秒刷盘，性能和安全折中，最多可能丢约 1 秒数据；
• no：交给操作系统决定，性能好但风险更高。

完整版教学

一、Redis 为什么需要持久化

Redis 是内存数据库，数据主要存在内存里。如果没有持久化，进程重启或机器宕机后数据会丢失。持久化的目标是把内存中的状态落到磁盘，便于恢复。

但持久化一定有成本：要么定期生成快照，要么记录写命令，要么两者都做。所以面试回答要讲清取舍，而不是只说“RDB 快，AOF 安全”。

缓存场景可以接受丢失，重启后从数据库回源即可；但如果 Redis 存会话、计数、队列、限流状态或部分业务状态，完全不持久化就可能造成明显业务影响。持久化方案要和数据重要性匹配：越希望少丢数据，写盘成本通常越高；越追求恢复快，快照基线越重要。

持久化目标：
进程重启后能恢复数据
机器故障后有可用备份
降低数据丢失窗口

二、RDB：保存某个时刻的完整快照

RDB 会把当前数据集保存成一个紧凑的二进制文件。它适合做备份和快速恢复，因为加载一个快照通常比重放大量命令快。

它的问题是数据丢失窗口。比如每 5 分钟生成一次 RDB，如果第 4 分 59 秒宕机，那么这段时间的写入可能丢失。

RDB 生成快照通常通过 fork 子进程完成。fork 本身和写时复制会带来内存和 CPU 压力，大实例上要关注生成快照时的延迟抖动。

举个数字例子：如果配置为 5 分钟生成一次快照，Redis 在第 4 分 50 秒宕机，那么这 4 分 50 秒内的写入可能丢失。RDB 文件通常更紧凑，适合全量备份和灾备留档；但它的安全性取决于快照频率，快照越频繁，fork 和写时复制压力也越频繁。

RDB 特点	说明
文件紧凑	适合备份和快速加载
时间点快照	两次快照之间可能丢数据
fork 子进程	大实例可能有内存和延迟压力
恢复快	不需要重放大量历史命令

三、AOF：把写命令追加到日志

AOF 会把 Redis 接收到的写命令按顺序追加到文件。重启时 Redis 重放这些命令恢复数据。

AOF 的优势是数据丢失窗口更小，尤其是 appendfsync everysec 策略，在性能和安全之间比较均衡。它的代价是文件会不断增长，需要 AOF rewrite 把历史命令压缩成更短的等价命令集合。

比如同一个 key 被 incr 了一万次，rewrite 后可以变成一次设置最终值的命令，从而减少文件大小和恢复成本。

appendfsync everysec 是常见折中：Redis 每秒左右刷盘一次，机器突然掉电时理论上可能丢最近约 1 秒写入；always 每次写都刷盘，安全性更高但吞吐和延迟代价明显；no 交给操作系统，性能好但丢失窗口不可控。AOF 更关注数据安全窗口，代价是文件增长和恢复重放成本。

appendfsync:
always   -> 每次写刷盘，慢但更安全
everysec -> 每秒刷盘，常用折中
no       -> OS 决定刷盘，风险更高

记忆钩子：RDB 像定期拍照片，AOF 像持续记流水；照片恢复快，流水丢得少但要压缩。

四、混合持久化为什么常见

Redis 支持 AOF 重写时使用 RDB 格式作为文件前半部分，再追加增量 AOF。这样恢复时先加载紧凑快照，再重放少量增量命令。

混合持久化的思路很自然：RDB 负责快速基线，AOF 负责降低丢失窗口。对于大多数既要恢复速度又要较高安全性的场景，这是比单独使用某一种更均衡的选择。

混合持久化不是同时保留两份完全独立文件那么简单，它的恢复思路是先读 RDB 格式的基线，再读后续 AOF 增量。这样避免纯 AOF 文件过长导致恢复慢，也比单纯 RDB 减少数据丢失窗口。生产中还要关注 rewrite 期间磁盘空间是否充足，因为旧 AOF 和新 AOF 可能在一段时间内同时存在。

五、持久化不能替代高可用

持久化解决的是重启恢复，不等于高可用。单机 Redis 即使持久化做得很好，机器宕机期间服务仍然不可用。

要提高可用性，还需要主从复制、Sentinel、Cluster、备份策略和灾备演练。持久化是数据安全的一环，不是完整容灾方案。

比如 Redis 主机宕机，RDB/AOF 可以帮助你在新机器上恢复数据，但恢复期间服务可能不可用；主从和 Sentinel 可以把从节点提升为主节点，缩短不可用时间；备份和异地灾备则应对更大范围故障。持久化管“数据怎么回来”，高可用管“服务怎么继续”。

六、如何按场景选择

纯缓存且可从数据库重建，可以弱化持久化，把重点放在容量、淘汰和回源保护；需要更小数据丢失窗口的业务，通常开启 AOF everysec 或混合持久化；需要备份留档和快速恢复，则保留 RDB。无论选哪种，都要做恢复演练，否则配置写得再漂亮，真正故障时也可能发现文件损坏、磁盘不足或恢复时间超预期。

选择思路：
只做缓存 -> 可降低持久化要求
要少丢数据 -> AOF everysec/always
要快速恢复 -> RDB 或混合持久化
要高可用 -> 主从/Sentinel/Cluster 另行设计

七、常见误区与追问

• 误区：RDB 比 AOF 永远更好。 RDB 恢复快、文件小，但快照间隔内可能丢数据，适不适合取决于业务容忍度。
• 误区：AOF 开启后就不会丢数据。 AOF 丢失窗口取决于 fsync 策略，everysec 仍可能丢最近约 1 秒数据。
• 误区：AOF 文件只会越来越大没法处理。 AOF rewrite 会把历史命令压缩成等价的更短数据集表示。
• 误区：有持久化就等于高可用。 持久化解决恢复，高可用还需要主从、Sentinel、Cluster 和客户端切换。
• 追问：混合持久化为什么恢复更快？ 它先加载紧凑 RDB 基线，再重放少量 AOF 增量，避免纯 AOF 长日志全量重放。
• 追问：RDB fork 有什么风险？ 大实例 fork 和写时复制会带来内存峰值和延迟抖动，磁盘慢时也会影响稳定性。

八、加强记忆

RDB 是时间点快照，文件紧凑、恢复快，但可能丢最近一次快照后的写入；AOF 是写命令日志，数据丢失窗口更小，但文件会增长，需要 rewrite，恢复速度取决于日志规模。混合持久化用 RDB 做基线、AOF 补增量，兼顾恢复速度和安全窗口。持久化只回答“重启后数据怎么恢复”，不回答“故障时服务是否继续可用”，高可用还要靠主从、Sentinel、Cluster 和演练。