大家好，我是程序员二叉。
简介
Redis基于内存运行，宕机后内存数据全部丢失，持久化是保障数据落地磁盘的核心机制。本文全面梳理RDB快照、AOF日志、AOF重写、混合持久化底层原理、优缺点与适用场景，附带宕机完整恢复流程，覆盖面试高频考点与线上落地规范。欢迎点赞收藏关注。
一、RDB持久化
1. 定义
RDB是Redis默认持久化方案，某一时间点全量内存二进制快照，落地为rdb文件。
2. 原理
主线程fork子进程，依托COW写时复制；子进程遍历全量内存生成二进制快照，新文件生成后替换旧RDB，子进程操作不阻塞主线程。
3. 触发方式
- 手动：
save(阻塞主线程)、bgsave(后台异步) - 自动：save配置规则、shutdown关机、flushall、主从全量同步
4. 优点
- 二进制压缩存储，文件体积小，故障恢复速度极快
- 子进程异步落地，主线程性能损耗低
- 适合冷备份、跨机器容灾备份
5. 缺点
- 两次快照间隔宕机，中间新增数据全部丢失
- fork子进程瞬间占用双倍物理内存，大内存实例易卡顿
二、AOF持久化
1. 定义
以追加日志形式记录所有客户端写指令，重启通过重放指令恢复数据。
2. 三种刷盘策略
- always：每条写命令立刻刷磁盘，零丢数据，性能最差
- everysec：每秒统一刷盘，默认配置，最多丢失1s数据，均衡性能与安全
- no：交给操作系统自主刷盘，性能最优，丢失数据不可控
3. AOF重写原理
fork子进程，直接读取当前内存数据，合并冗余指令生成最简新AOF；重写期间新增写命令存入aof重写缓冲区，重写结束后追加至新文件，原子替换旧AOF。
4. 重写目的
- 消除冗余指令(多次修改同一个key、del无效数据)，缩减文件体积
- 减少重启重放指令数量，加快数据恢复速度
三、RDB与AOF对比
| 对比项 | RDB | AOF |
|---|---|---|
| 存储格式 | 二进制快照 | 文本指令日志 |
| 数据丢失 | 间隔内全丢 | everysec仅丢1秒 |
| 文件大小 | 小 | 偏大 |
| 恢复效率 | 极快 | 偏慢 |
| 适用场景 | 周期性冷备份 | 线上实时数据持久化 |
四、混合持久化(Redis4.0+)
原理
开启aof-use-rdb-preamble，AOF文件头部为RDB全量快照，尾部是增量AOF日志。
优势
兼具RDB恢复快、AOF数据安全的优点，生产环境主流配置。
五、Redis宕机数据恢复流程
- Redis启动优先检查AOF文件是否开启
- 开启AOF：
- 混合持久化：先加载头部RDB快照，再顺序重放尾部增量AOF日志
- 纯AOF：从头到尾重放全部写命令
- 未开启AOF：直接加载本地最新RDB文件恢复数据
- 数据加载完毕，启动成功对外提供服务
总结
- RDB：全量快照，适合定期备份，存在丢数风险；
- AOF：日志追加，数据安全性高，everysec是最优刷盘配置，依靠重写压缩日志；
- 混合持久化融合两者优点，线上推荐开启；
- 重启恢复优先级：混合AOF > 纯AOF > RDB。
