📌 Redis持久化机制详解：RDB与AOF原理、实现流程与生产实践

1️⃣ 问题背景

Redis是一个基于内存的高性能Key-Value数据库，其绝大多数数据都存储在内存中。内存虽然访问速度极快，但存在一个天然缺陷：断电即丢失。

如果Redis服务器突然宕机、进程崩溃或者机器断电，内存中的数据将全部消失。对于缓存场景来说问题不大，但对于用户信息、订单状态、库存数据等核心业务数据而言，这是无法接受的。

因此Redis设计了持久化机制，将内存中的数据定期保存到磁盘。当Redis重启时，可以从磁盘恢复数据，从而保证数据不会因为服务器故障而全部丢失。

Redis目前主要支持两种持久化机制：RDB（Redis Database）和AOF（Append Only File）。

2️⃣ 核心原理

Redis持久化的本质目标是将内存中的数据同步到磁盘。

RDB采用快照机制，将某一时刻的全部数据一次性保存到磁盘；AOF采用日志机制，将每一条写命令记录到文件中。

简单理解：

3️⃣ 数据结构分析

RDB文件结构

RDB文件是一个经过压缩的二进制文件。

RDB文件中保存的是Redis在某个时间点的完整数据快照。

AOF文件结构

AOF本质是命令日志文件。

Redis重启时会重新执行这些命令，从而恢复数据。

Redis Fork机制

无论是RDB还是AOF重写，都依赖Linux的Fork机制。

Fork之后采用Copy-On-Write技术，避免大量数据复制带来的性能损耗。

4️⃣ 算法分析

RDB快照算法

Redis通过BGSAVE命令触发快照生成。

含义如下：

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

满足任意条件即可触发快照生成。

AOF追加算法

每次执行写命令时，Redis会将命令追加到AOF缓冲区。

同步策略由appendfsync决定。

AOF重写算法

随着运行时间增长，AOF文件会越来越大。

Redis通过BGREWRITEAOF进行日志压缩。

最终仅保留恢复数据所需的最少命令。

5️⃣ 执行流程

RDB执行流程

AOF写入流程

Redis启动恢复流程

6️⃣ 实际案例

RDB配置

该配置表示Redis自动生成快照文件dump.rdb。

开启AOF

AOF同步策略

每条命令立即刷盘，安全性最高。

每秒刷盘一次，是生产环境最常用配置。

交给操作系统决定刷盘时机。

Redis 7.0混合持久化

Redis 4.0开始支持RDB+AOF混合持久化。

重写AOF时，前半部分采用RDB格式保存数据，后半部分记录增量命令。

这种方式兼顾恢复速度与数据安全性。

7️⃣ 优缺点分析

RDB优缺点

AOF优缺点

RDB与AOF对比

维度	RDB	AOF
数据安全	一般	高
恢复速度	快	慢
文件大小	小	大
性能影响	较低	较高

8️⃣ 面试常见问题

Q1：Redis为什么需要持久化？

Q2：RDB和AOF有什么区别？

Q3：Redis启动优先加载哪个文件？

Q4：为什么AOF需要重写？

Q5：生产环境推荐哪种方案？

Q6：什么是Copy-On-Write？

9️⃣ 总结

Redis持久化主要依赖RDB和AOF两套机制。RDB通过生成数据快照实现快速备份与恢复；AOF通过记录写命令实现更高的数据安全性。

RDB适合灾备恢复和全量备份，AOF适合保证数据完整性。在现代生产环境中，Redis通常采用RDB+AOF混合持久化模式，以兼顾性能、恢复速度和数据可靠性。