Redis持久化

一、概述

Redis是内存数据库，断电、进程宕机都会造成内存数据丢失。持久化就是将内存数据落地到磁盘，服务重启后从磁盘文件恢复数据。Redis提供两种持久化方案：RDB快照、AOF日志，生产环境推荐同时开启。

二、RDB（Redis Database，数据快照）

1. 定义

全量快照，在某一时刻将Redis全部内存数据压缩，写入.rdb二进制文件；数据恢复时直接加载完整快照文件。

2. 三种触发方式

1. save：主进程同步执行，全程阻塞Redis所有读写命令，生产环境禁止使用。
2. bgsave：后台异步执行，主进程fork出子进程完成数据落盘，不阻塞主线程，为主流使用方式。
3. 配置自动触发（redis.conf）

save 900 1
save 300 10
save 60 10000

3. fork+写时复制（COW）底层原理

1. 执行bgsave时，操作系统fork创建子进程，子进程与主进程共享同一份物理内存页表。
2. 子进程遍历内存数据，将数据写入RDB磁盘文件。
3. 主进程执行读操作：继续共享原有内存数据。
4. 主进程执行写操作：触发写时复制，复制被修改的内存页，在新内存副本上完成修改；子进程依旧读取原始内存数据，保证快照数据一致性。

4. RDB优缺点

优点：文件经过压缩，占用体积小；故障数据恢复速度极快。 缺点：两次快照之间新增的数据不会落地，服务故障会丢失该时间段内全部数据。

三、AOF（Append Only File，追加命令日志）

1. 定义

记录每一条增、删、改类写命令，按照Redis协议格式追加写入.aof文本文件。服务重启时，逐条重放日志命令还原数据，该功能默认关闭。

开启配置：

appendonly yes
appendfilename "appendonly.aof"

2. 三种刷盘策略（appendfsync）

配置	刷盘时机	优点	缺点
always	执行写命令后立即落盘	数据安全性最高，几乎不丢失数据	频繁产生磁盘IO，性能极差
everysec（默认）	缓冲区每秒统一执行刷盘	性能与安全性均衡	极端情况最多丢失1秒数据，生产环境标配
no	交由操作系统自主调度刷盘	性能最优	服务宕机可能丢失大量数据

3. AOF重写（AOF rewrite）

随着运行时间增加，重复命令会导致AOF文件持续膨胀。AOF重写会根据当前内存中的真实数据，生成最简执行指令，创建新AOF文件并替换旧文件，以此压缩文件体积。

4. AOF优缺点

优点：数据完整性高，默认配置下仅可能丢失秒级数据。 缺点：以文本形式存储命令，文件体积远大于RDB；数据恢复时需要逐条回放指令，恢复速度很慢。

四、RDB vs AOF 对比汇总

对比项	RDB	AOF
持久化形式	定时全量内存快照	实时追加写命令日志
数据完整度	较低，两次快照间数据会丢失	较高，默认配置最多丢失1秒数据
文件体积	二进制压缩，体积小	文本存储指令，体积大
恢复速度	极快，直接加载全量数据	缓慢，逐条回放命令
资源开销	fork子进程，CPU开销偏高	频繁磁盘IO，IO开销偏高
适用场景	可容忍分钟级数据丢失、追求快速启动	要求高数据安全性，无法接受大量数据丢失

五、生产落地规范

生产环境同时开启RDB+AOF：

1. 服务故障优先使用AOF恢复数据，保证数据完整性。
2. RDB用于冷备份、跨机器数据迁移，兼顾恢复效率。

六、面试高频问题解析

1. 问：Redis如何防止宕机丢失数据？

   答： 开启RDB和AOF双持久化。RDB定时生成全量快照做冷备份，AOF采用everysec刷盘策略保证秒级数据落地。服务宕机后优先通过AOF恢复数据，RDB可用于数据迁移与异地备份。

2. 问：save和bgsave有什么区别？

   答： save是同步执行，阻塞所有读写请求，生产禁用；bgsave异步fork子进程执行，不影响主线程对外提供服务，是日常使用的快照方式。

3. 问：bgsave的写时复制原理是什么？

   答： fork出的子进程和主进程共享内存页表。主进程读数据不受影响，当主进程修改数据时，系统会复制对应内存页，主进程操作新副本，子进程继续读取原始内存数据，保障快照数据一致。

4. 问：AOF三种刷盘策略各自特点和使用场景？

   答： always实时落盘，数据最安全但性能差；everysec每秒刷盘，性能和安全性均衡，为生产默认选择；no交由系统调度，性能最好但丢数据风险高。

5. 问：为什么生产环境建议RDB和AOF一起使用？

   答： AOF数据完整性更强，作为主力恢复方案；RDB文件小、恢复快，适合做冷备份和数据迁移，二者结合兼顾数据安全与运行效率。