Redis 持久化策略

Redis 为什么需要持久化？

Redis 是基于内存的数据库，内存访问速度快，但内存数据在进程退出或机器宕机后必然丢失。因此，Redis 提供持久化机制，将内存中的数据以一定策略写入磁盘，用于服务重启后的数据恢复。

需要明确一个前提结论：

Redis 持久化只能降低数据丢失风险，并不能保证强一致性或绝对不丢数据。
实际丢失多少数据，取决于持久化策略、刷盘频率以及宕机发生的时间点。

Redis 提供两种核心持久化机制：

AOF（Append Only File）日志
RDB（Redis DataBase）快照

AOF 日志持久化

AOF 是什么

AOF（Append Only File）通过记录写命令的方式持久化数据。Redis 会将所有会修改数据的命令，按执行顺序追加写入日志文件。

AOF 默认是关闭的，可通过配置开启：

1 2	appendonly yes appendfilename "appendonly.aof"

AOF 只记录写操作命令，不记录读操作，因为读命令无法用于数据恢复。

AOF 的写入流程

一次写命令的大致流程如下：

Redis 执行写命令，修改内存数据
将写命令追加到 AOF buffer
根据 appendfsync 策略，决定是否调用 fsync() 将数据刷入磁盘

注意：
AOF 持久化写入的是命令本身，而不是数据结果。

AOF 的刷盘策略

Redis 提供三种 AOF 刷盘策略：

appendfsync always
- 每条写命令都调用 fsync()
- 数据安全性最高
- 性能最差
appendfsync everysec（默认）
- 每秒刷盘一次
- 宕机时最多丢失 1 秒的数据
- 性能和安全性较为平衡
appendfsync no
- 不主动刷盘，由操作系统决定
- 宕机时可能丢失操作系统缓冲区中的全部数据
- 数据丢失量不可控

AOF 文件膨胀与重写机制

由于 AOF 会持续追加写命令，文件体积会不断增大。为此，Redis 提供 AOF 重写（rewrite）机制。

需要强调的是：

AOF 重写并不是简单地“压缩旧 AOF 文件”，
而是根据当前内存中的数据状态，重新生成一份等价的最小命令集。

AOF 重写过程

Redis fork 出一个子进程
子进程根据当前内存数据生成新的 AOF 文件
重写期间，主进程的新写命令写入：
- 原 AOF 文件
- AOF 重写缓冲区
重写完成后：
- 将重写缓冲区中的命令追加到新 AOF 文件
- 原子性替换旧 AOF 文件

fork 与写时复制（Copy-On-Write）

fork 时子进程共享父进程的内存页
主进程发生写操作时，通过写时复制保证子进程的数据一致性
重写过程不会阻塞正常的写请求

RDB 快照持久化

RDB 是什么

RDB 通过生成某一时刻内存数据的完整快照来持久化数据，类似于给 Redis 的数据拍一张“照片”。

RDB 默认开启。

RDB 的生成方式

Redis 提供两个命令生成 RDB 文件：

save
- 在主线程执行
- 完全阻塞 Redis
bgsave
- fork 子进程生成快照
- fork 时存在短暂阻塞
- 是生产环境常用方式

RDB 通常通过配置自动触发：

1
2
3

save 900 1
save 300 10
save 60 10000

含义为：

900 秒内至少 1 次修改
300 秒内至少 10 次修改
60 秒内至少 10000 次修改

满足任意条件，Redis 就会执行 bgsave。

RDB 的特点与风险

RDB 是全量快照
每次生成都会遍历并序列化所有数据
快照操作相对较重

因此：

执行频率高 → 性能开销大
执行间隔长 → 宕机时数据丢失多

RDB 本质上是一个：
重操作 + 恢复快 + 丢数据多 的方案。

Redis 启动时的数据恢复流程

Redis 重启后，持久化文件的加载顺序为：

如果开启了 AOF，且 AOF 文件存在
→ 优先使用 AOF 文件恢复数据
否则使用 RDB 文件恢复数据
若两者都不存在
→ 数据为空

注意：
“同时开启 AOF 和 RDB”并不意味着“同时恢复”，
而是 AOF 在恢复阶段具有更高优先级。

AOF 与 RDB 的对比

对比维度	AOF	RDB
数据安全性	较高（可配置）	较低
数据丢失量	秒级或可控	取决于快照周期
持久化开销	较轻	较重
文件体积	较大	较小
恢复速度	较慢	较快
适用场景	对数据可靠性要求较高	缓存、允许丢数据