redis持久化

Redis 持久化主要包含 ‌RDB 快照、AOF 日志、混合持久化‌ 三种主流方式，各自的实现逻辑、优缺点和适用场景差异明显，以下是详细说明：

一、RDB 快照持久化

实现原理

Redis 触发持久化时，通过 fork() 系统调用创建一个子进程，子进程将当前内存中的全量数据以二进制快照形式写入 dump.rdb 文件，主进程全程不参与 IO 操作，避免阻塞服务。触发方式分为手动执行 SAVE/BGSAVE，或通过配置文件设置自动快照触发条件（如900秒内至少1次写操作）。

优缺点

‌优点‌：文件紧凑占用空间小，重启恢复速度极快，非常适合大规模数据的冷备份和灾难恢复。

‌缺点‌：存在数据丢失风险，两次快照之间的新数据无法被持久化；数据量极大时，fork 子进程的操作可能阻塞服务数毫秒至数秒。

二、AOF 日志持久化

实现原理

开启后，Redis 会将每一条收到的写操作命令以追加的形式写入 appendonly.aof 日志文件。Redis 重启时，会通过逐条重放 AOF 中记录的写命令，完整恢复内存数据。同时支持后台 AOF 重写机制，自动清理冗余重复命令，压缩文件体积。

优缺点

‌优点‌：数据安全性极高，通过配置 appendfsync everysec 最多仅丢失1秒内的数据；文件为纯命令文本，可读性强，便于紧急场景下手动修复数据。

‌缺点‌：长期运行后文件体积会比 RDB 大很多；重启全量重放命令的恢复速度远慢于 RDB；开启后写操作需要同步写日志，写性能会有小幅下降。

三、混合持久化（Redis 4.0+ 支持）

实现原理

同时开启 RDB 和 AOF 持久化，执行 AOF 重写时，将当前内存中的全量数据以 RDB 二进制格式写入 AOF 文件的开头部分，后续再追加增量的 AOF 命令。重启时优先加载 AOF 文件，既利用 RDB 快速恢复全量数据，又保留了 AOF 的增量数据完整性。

优缺点

‌优点‌：完美兼顾 RDB 的快速恢复能力和 AOF 的数据完整性，提供多层次的数据保护，大幅降低重启加载耗时。

‌缺点‌：相比单一持久化方式，会消耗更多磁盘空间和 IO 资源，配置逻辑相对复杂。

对比汇总表

持久化方式	数据丢失风险	恢复速度	磁盘占用	适用场景
RDB	可能丢失最后一次快照后的数据	极快	小	大规模数据备份、灾难恢复
AOF	最多丢失1秒数据	慢	大	对数据安全性要求极高的场景
混合持久化	几乎不丢数据	快	中等	生产环境主流推荐方案