Redis 持久化方式有哪些，各有何优劣？

核心回答

Redis 主要有 RDB 快照和 AOF 日志两种持久化机制，可以同时使用；常说的混合持久化，是在 AOF 的基础数据部分采用 RDB 格式，再记录后续增量。选择时主要比较三点：能接受丢多少数据、希望多快恢复，以及愿意承担多少内存和磁盘 IO 开销。

• RDB 保存某个时间点的数据集快照，文件通常较紧凑，适合保存历史备份和较快恢复。缺点是两次快照之间的修改没有全部落入这个快照，异常宕机时可能丢失最近一次成功快照之后的数据；后台生成也有 fork、写时复制和 IO 成本。
• AOF 追加能够恢复数据变化的写操作记录，重启时加载并重放，数据丢失窗口取决于同步策略。它可以比低频快照更及时地保存修改，但持续写日志和刷盘会产生开销，文件会增长，需要重写；纯命令日志通常也比对应快照加载更慢。
• 混合持久化 先加载 RDB 格式的基础数据，再重放 AOF 增量，兼顾基础数据加载与后续修改恢复。它没有消除 AOF 的刷盘窗口，也不等于同时存在一个独立 dump.rdb 文件就自动完成了混合持久化。

如果数据可以从主数据库重建，可以根据冷启动和回源压力选择较轻的持久化策略，必要时也能关闭持久化。如果恢复要求更高，常见做法是配置 AOF，并保留定期快照及独立备份；具体同步策略和快照频率应由业务恢复目标决定。

RDB 后台生成怎样保持一致

SAVE 会在主线程生成快照，期间不能正常处理其他命令；BGSAVE 则通过 fork 创建子进程，由子进程生成快照。

fork 后，父子进程起初共享物理内存页。父进程继续处理写请求时，操作系统通过写时复制保留子进程看到的旧页面，父进程修改自己的页面。因此，子进程能够写出对应 fork 时刻的数据视图，而不是把快照期间的新旧值随意混在一起。

BGSAVE 也不是完全没有影响：fork 本身可能带来停顿，快照期间的大量写入会增加页面复制与额外内存，写文件还会占用磁盘带宽。快照完成的时间也不是快照数据对应的时间，刚完成快照后宕机，仍可能丢失生成期间的修改。

AOF 的三种同步策略

要区分“已经修改内存”“已经写入操作系统文件缓存”和“已经完成磁盘同步”。客户端收到成功响应，并不在所有策略下都表示这次写入已经持久化。

• always：追加后同步 AOF，按该策略完成同步再返回响应，耐久性较强，写入延迟和 IO 成本也更高。Redis 可以合并一批写入进行同步，并不是每条命令都必然对应一次独立 fsync。
• everysec：通常每秒在后台执行同步，在性能和丢失窗口之间折中。常见说法是可能丢失最近约一秒的修改，但这不是所有磁盘故障、阻塞和配置条件下都成立的硬上限。
• no：Redis 不主动安排这类 fsync，由操作系统决定何时刷盘，丢失窗口更依赖系统行为，不能承诺固定秒数。

即使使用 always，也不能把它解释为磁盘损坏、文件丢失或故障切换下绝不丢数据。策略控制的是特定持久化路径上的同步行为，不能替代其他恢复措施。

AOF 重写和混合持久化怎么配合

重写是根据当前数据集生成新的基础记录，去掉恢复当前状态不再需要的历史操作，不是读取旧日志后逐条做文本去重。例如一个计数器被连续增加很多次，恢复当前值不必保留每一次增加动作。因此 AOF 也不能被当作永久完整的业务审计历史。

从 Redis 7.0 起采用多文件 AOF：基础文件最多一个，可以使用 RDB 或 AOF 格式；另外保存增量文件，并由 manifest 管理有效文件集合。重写期间，子进程生成新的基础文件，父进程把新修改写入新的增量文件；准备完成后切换清单，再清理不再需要的旧文件。不能再把旧版“所有增量最后合并到单个新 AOF”的流程当成所有版本的实现。

基础文件使用 RDB 格式时，恢复先加载基础快照，再重放清单中的增量命令。重写和后台快照同样要预留内存、磁盘空间与 IO 余量；备份多文件 AOF 时，还要得到清单及其引用文件的一致集合，不能只复制任意一个文件。

常见追问

同时开启 RDB 和 AOF，重启加载哪个？

在常规启动配置下，两者都启用时 Redis 使用 AOF 恢复，因为它通常包含更完整的修改。若 AOF 的基础部分是 RDB 格式，加载它属于 AOF 文件集的恢复过程，与“先加载独立 RDB，再随意补一个日志”不同。

有复制副本，还需要持久化和备份吗？

它们解决的问题不同：持久化帮助实例从本地文件恢复，复制将数据同步到其他实例以支持可用性和扩展，备份保留可回退的历史版本。Redis 默认异步复制，切换时可能存在尚未复制的写入；误删也可能同步到副本，所以副本不能代替独立历史备份。

实际验证应包含持久化是否成功、磁盘和 fork 开销，以及备份能否恢复、恢复后的数据是否符合业务预期，不能只看配置里打开了开关。

参考资料