一、前言：为什么Redis需要持久化？
Redis 是一款基于内存的高性能数据库，所有数据默认存储在内存中，读写速度极快，但内存数据具有易失性。一旦服务器断电、进程崩溃、机器重启，内存中的所有数据会全部丢失。
而 Redis 持久化机制的核心作用就是：将内存中的数据定期存储到磁盘，保证服务重启后能够恢复数据，避免数据丢失。
二、Redis持久化整体概述
Redis 官方提供了两种独立的持久化方式，二者可单独开启，也可混合开启。
-
RDB（Redis Database Backup）：数据快照，将某一时刻的全量内存数据，以二进制文件形式保存到磁盘。
-
AOF（Append Only File）：将客户端执行的每一条写命令，都写入磁盘，重启时读取AOF文件恢复数据。
三、RDB 持久化（快照持久化）
3.1 核心原理
RDB 是全量快照持久化，Redis 会在指定时间间隔内，将内存中所有数据以二进制方式存储到文件，保存到磁盘。
其核心实现依赖 fork 子进程：Redis 主进程不会执行 IO 操作，而是通过 fork 创建子进程，由子进程对当前父进程内存数据的复制，并写入到新的AOF文件中。
fork 机制特点：采用写时复制（COW），fork 瞬间子进程共享父进程内存数据，若父进程后续有新的写操作，操作系统会复制对应内存页给父进程，父进程在新的内存页上面进行修改，子进程还持有原来内存数据，不受影响。
3.2 RDB 触发方式
RDB 分为自动触发 和手动触发两种场景：
1，自动触发
在配置文件中设置 save + 时间 + 触发多少次 这样的配置来自动触发RDB
2，手动触发（客户端命令）
save ：主进程直接执行 RDB 持久化，阻塞主线程，数据量大时会导致 Redis 卡顿，生产环境禁止使用。
bgsave ：后台触发，fork 子进程执行持久化，不阻塞主进程，对于生产环境手动触发首选。
3，特殊自动触发场景
执行flushall，flushdb清空数据时，会自动触发 RDB，保存空数据快照；
Redis 正常关机（shutdown）时，会自动执行 bgsave 持久化。
3.4 RDB 数据恢复流程
Redis 启动时，会自动读取当前目录下的 dump.rdb 文件，将快照数据加载到内存，完成数据恢复。
优先级规则：同时存在 RDB 和 AOF 文件时，优先加载 AOF 文件（AOF 数据完整性更高）。
3.5 RDB 优缺点总结
优点
-
文件体积小：二进制压缩文件，存储全量数据，占用磁盘空间远小于 AOF 日志；
-
恢复速度快：直接加载全量快照，无需重放日志，大数据量恢复效率极高；
-
性能损耗低：bgsave 依赖子进程，主进程几乎无 IO（程序和外部设备交换数据的操作都叫IO） 阻塞；
-
适合冷备份：文件精简，适合定时归档、异地备份。
缺点
-
存在数据丢失风险：两次快照之间的增量数据未落地，若进程宕机，会丢失上一次快照后的新数据；
-
fork 耗时问题：大数据量（GB级）场景，fork 子进程会耗时较高，短暂阻塞主线程；
-
不适合高频持久化：频繁快照会大量消耗 CPU、磁盘 IO 资源。
四、AOF 持久化（日志持久化）
4.1 核心原理
AOF 是增量日志持久化 ，核心逻辑是：记录客户端所有写操作命令（增、删、改，忽略读命令），以追加的方式写入日志文件。
Redis 重启恢复数据时，会读取 AOF 日志中的命令，重新执行一遍，还原内存数据。AOF 是实时性更高的持久化方案，最大程度减少数据丢失。
4.2 AOF 核心执行流程
AOF 持久化分为三个核心步骤，全程不阻塞主进程：
-
命令追加 ：客户端执行写命令后，Redis 将命令格式化、校验后，追加到AOF 内存缓冲区域，积累一段时间后再统一写入到磁盘。流程如下：
-
-
文件写入：根据配置的刷盘机制，将缓冲区数据写入磁盘 AOF 文件；
-
文件重写：AOF 日志会持续膨胀，Redis 会定期重写日志，达到精简文件，缩小文件体积的目的
4.3 AOF 三种刷盘配置
刷盘策略决定了数据写入磁盘的时机，直接影响数据安全性和性能
| 策略 | 配置值 | 执行逻辑 | 数据安全性 | 性能 |
|---|---|---|---|---|
| 每秒刷盘（默认） | appendfsync everysec | 缓冲区数据每秒统一刷盘一次 | 安全性高，最多丢失1秒内的数据 | 均衡，生产默认首选 |
| 实时刷盘 | appendfsync always | 每执行一条写命令，立即刷盘 | 最高，无数据丢失 | 极差，高频场景严重拖慢性能 |
| 系统自动刷盘 | appendfsync no | 交由操作系统决定刷盘时机 | 最低，但可能丢失大量数据 | 最高，几乎无性能损耗 |
4.4 AOF 日志重写机制
随着内存的数据量越来越多，AOF 文件会持续变大，但会存在大量冗余命令吗，比如多次修改同一个 key、重复删除无效 key，导致文件变大、重启恢复缓慢。为此 Redis 提供 了AOF 重写机制。重写流程如下：
重写核心逻辑
Redis fork 子进程，遍历当前内存所有数据（当前内存的数据就是最终的key的状态），生成新的AOF文件替换旧的冗余 AOF 文件，大幅压缩文件体积。
注意：redis7版本之后移除了父进程内存缓冲区，重写期间新增命令直接写入独立的增量AOF文件，不再写入缓冲区，同时也不需要一边重写一边持续追加旧的AOF文件。
重写机制的触发
4.5 AOF 数据恢复流程
-
Redis 启动时检测
appendonly.aof文件； -
校验文件完整性，修复末尾不完整命令（支持兼容宕机残留的残缺日志）；
-
逐行重放日志中的写命令，还原内存数据。
4.6 AOF 优缺点总结
优点
-
数据安全性极高：默认每秒刷盘，最多丢失1秒数据，可配置实时刷盘实现零丢失；
-
日志容错性强：支持修复残缺日志，宕机残留的不完整命令不会导致服务启动失败；
-
增量写入效率高：无需全量遍历数据，仅追加写命令，日常性能损耗低。
缺点
-
文件体积大：日志存储所有写命令，即使重写后，体积仍远大于 RDB 文件；
-
数据恢复慢：需要逐行重放命令，大数据量场景恢复效率远低于 RDB；
-
高频 IO 损耗：实时/每秒刷盘会持续消耗磁盘 IO，极端场景影响吞吐量。
五、RDB 与 AOF 核心对比（超全对照表）
| 对比维度 | RDB | AOF |
|---|---|---|
| 持久化类型 | 全量快照 | 增量日志 |
| 数据丢失率 | 较高，丢失两次快照间增量数据 | 极低，最多丢失1秒数据 |
| 文件体积 | 小，二进制压缩文件 | 大，文本命令日志 |
| 恢复速度 | 极快 | 较慢 |
| 性能损耗 | 定时高损耗，日常低损耗 | 持续低IO损耗，稳定均衡 |
| 容错能力 | 差，文件损坏直接无法恢复 | 强，支持修复残缺日志 |
| 适用场景 | 冷备份、快速恢复、数据容忍少量丢失 | 核心业务、高数据一致性场景 |
六、Redis 混合持久化（生产最优方案）
6.1 混合持久化原理
AOF 重写时，先将当前全量内存数据以 RDB 二进制格式 写入新 AOF 文件头部，再将后续增量写命令以 AOF 日志格式追加在尾部。
既拥有 RDB 文件小、恢复快 的优点，又保留 AOF 数据安全性高、增量写入效率高的优势。
6.2 混合持久化配置
redis5.0以上版本默认开启，图中配置项为yes代表开启
6.3 混合持久化优势
-
解决纯 AOF 重启恢复慢的问题，头部 RDB 快照快速落地全量数据；
-
解决纯 RDB 数据丢失多的问题，尾部 AOF 日志补齐增量数据；
-
大幅精简 AOF 文件体积，减少磁盘占用。
七、总结
1、RDB 是全量快照，胜在体积小、恢复快、性能稳定，短板是存在增量数据丢失风险，适合冷备份、非核心业务；
2、AOF 是增量日志，胜在数据安全性高、容错性强，短板是文件体积大、恢复速度慢，适合核心业务；
3、混合持久化 是 Redis 生产最优方案，取长补短，平衡数据安全、恢复速度和性能；