深入剖析 Redis 持久化：RDB 与 AOF 的全景解析

Redis 是一个高性能的内存数据库，但内存数据易失，一旦服务器宕机或重启，数据就会丢失。为了解决这个问题，Redis 提供了持久化机制，将内存中的数据保存到磁盘上。那么，Redis 的持久化方法有哪些？它们有什么不同？文件里到底存了什么？让我们从头开始，一步步拆解。

第一步：Redis 为什么需要持久化？

Redis 的核心优势是速度快，因为它把数据存储在内存中。但内存是易失性的，比如服务器断电、进程崩溃，数据就没了。为了保证数据的可靠性，Redis 提供了持久化功能，把内存中的数据定期或实时地写到磁盘上。这样即使发生意外，重启后也能通过磁盘文件恢复数据。

Redis 的持久化主要有两种方式：

RDB（Redis Database Backup）：快照方式。
AOF（Append Only File）：追加日志方式。

这两种方式各有千秋，下面我们逐步分析它们的原理、区别和实现细节。

第二步：RDB 是什么？怎么工作的？

RDB 的基本概念

RDB 是 Redis 默认的持久化方式，它会定期生成一个内存数据的快照（snapshot），保存到磁盘上的一个二进制文件（默认文件名是 dump.rdb）。这个快照是某一时刻 Redis 数据库的完整镜像。

RDB 的工作流程

触发快照 ：Redis 会在特定条件下生成快照，比如：
- 手动执行 SAVE 或 BGSAVE 命令。
- 配置了自动触发条件（比如 save 900 1，表示 900 秒内至少有 1 次写操作就触发）。
生成快照 ：
- SAVE：主线程直接执行，阻塞所有操作（不推荐生产使用）。
- BGSAVE：fork 一个子进程，子进程负责生成快照，主线程继续处理请求。
写文件：子进程将内存数据序列化成二进制格式，写入磁盘。
完成：生成新文件后替换旧文件。

RDB 的刷盘策略

RDB 的"刷盘"不是实时写入，而是基于触发条件。配置文件中的 save 参数决定了触发时机，例如：

bash 复制代码

save 900 1    # 900 秒内至少 1 次写操作
save 300 10   # 300 秒内至少 10 次写操作
save 60 10000 # 60 秒内至少 10000 次写操作

如果不满足条件，就不会生成快照。也可以设置 save "" 禁用 RDB。

RDB 文件长什么样？

RDB 文件是一个压缩的二进制文件，格式紧凑且高效。让我们看看它的结构（基于 Redis 7.0）：

文件头 ：
- 开头 5 个字节是固定的 REDIS 字符串，表示这是 RDB 文件。
- 接下来 4 个字节是版本号（比如 0009 表示版本 9）。
元数据 ：
- 存储一些辅助信息，比如 Redis 版本、创建时间等。
数据库部分 ：
- 一个 RDB 文件可以包含多个数据库（Redis 默认支持 16 个数据库，编号 0-15）。
- 每个数据库以 SELECTDB 操作码开头，后跟数据库编号。
- 然后是键值对数据，格式为：
  - 键的过期时间（可选）：如果有 TTL，用 8 字节存储。
  - 值类型：1 字节，表示值的类型（字符串、列表、哈希等）。
  - 键：长度编码的字符串。
  - 值：根据类型编码，比如字符串直接存内容，列表存元素序列。
文件尾 ：
- 8 字节校验和（CRC64），验证文件完整性。
- 结束标志 0xFF。

示例（简化版）

假设 Redis 中只有一个键值对：key1 -> "value1"，RDB 文件可能是：

bash 复制代码

52 45 44 49 53 30 30 30 39  # "REDIS0009"
FE 00                        # 数据库 0
00                           # 值类型：字符串
04 6B 65 79 31              # 键 "key1"（长度 4）
06 76 61 6C 75 65 31        # 值 "value1"（长度 6）
FF                           # 文件结束
<8字节校验和>

RDB 的优缺点

优点：
- 文件紧凑，适合备份和传输。
- 恢复速度快，直接加载到内存。
- fork 子进程不阻塞主线程。
缺点：
- 快照间隔时间内的数据会丢失（比如每 5 分钟保存一次，宕机时丢 5 分钟数据）。
- fork 大内存时可能影响性能。

第三步：AOF 是什么？怎么工作的？

AOF 的基本概念

AOF（Append Only File）通过记录每一次写操作命令来实现持久化。它的文件（默认是 appendonly.aof）是一个文本文件，保存了所有修改数据的命令，重启时通过重放这些命令恢复数据。

AOF 的工作流程

写命令 ：每次执行写操作（SET、DEL 等），Redis 把命令追加到 AOF 文件。
刷盘：命令先写入内存缓冲区，根据刷盘策略同步到磁盘。
重写（可选）：AOF 文件会不断变大，Redis 可以重写文件，只保留最简命令集。
恢复：重启时，读取 AOF 文件，逐条执行命令重建数据。

AOF 的刷盘策略

AOF 的刷盘由 appendfsync 参数控制，有三种选项：

no：不主动刷盘，交给操作系统决定（通常 30 秒一次）。可能丢数据，但性能最高。
everysec（默认）：每秒刷盘一次，由后台线程执行。最多丢 1 秒数据，性能和可靠性平衡。
always：每次写操作都刷盘。数据最安全，但性能最低（受磁盘 I/O 限制）。

配置文件示例：

bash 复制代码

appendonly yes
appendfsync everysec

AOF 文件长什么样？

AOF 文件是纯文本，记录 Redis 协议格式的命令。假设执行了以下操作：

sql 复制代码

SET key1 value1
SET key2 value2
DEL key1

AOF 文件可能是：

bash 复制代码

*3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n$6\r\nvalue1\r\n
*3\r\n$3\r\nSET\r\n$4\r\nkey2\r\n$6\r\nvalue2\r\n
*2\r\n$3\r\nDEL\r\n$4\r\nkey1\r\n

*n 表示命令有 n 个参数。
$n 表示后面字符串长度为 n。
\r\n 是换行符。

重写后的 AOF

如果执行 BGREWRITEAOF，Redis 会分析当前数据状态，生成最简命令。例如上面操作后，只剩 key2 -> value2，重写后可能是：

bash 复制代码

*3\r\n$3\r\nSET\r\n$4\r\nkey2\r\n$6\r\nvalue2\r\n

AOF 的优缺点

优点：
- 数据更安全，丢失量少（取决于刷盘策略）。
- 文件可读，便于调试和修改。
缺点：
- 文件体积大，增长快。
- 恢复速度慢，需要逐条执行命令。

第四步：RDB 和 AOF 的对比

特性	RDB	AOF
持久化方式	快照，某一时刻全量数据	日志，记录每次写操作
文件格式	二进制，紧凑	文本，Redis 协议
数据丢失	可能丢间隔时间数据	最多丢 1 秒（everysec）
恢复速度	快，直接加载	慢，逐条执行
文件大小	小，压缩后更小	大，随操作增加
性能影响	fork 时有开销	刷盘策略影响性能
使用场景	冷备份，允许丢少量数据	高可靠性需求

混合模式

Redis 4.0 引入了混合持久化：默认用 RDB 快照，增量变化用 AOF 记录。重启时先加载 RDB，再执行 AOF 增量命令，既保证恢复速度，又减少数据丢失。

第五步：实际应用中的选择

只用 RDB：适合数据丢失可接受的场景，比如缓存服务。
只用 AOF：需要高可靠性，比如订单数据。
RDB + AOF：兼顾恢复速度和数据安全，比如电商系统。

刷盘策略的选择也很关键：

appendfsync always：金融系统，数据零丢失。
appendfsync everysec：大多数场景，平衡性能和可靠性。
appendfsync no：高吞吐量场景，不在意少量丢失。

总结

Redis 的持久化通过 RDB 和 AOF 提供了灵活的选择。RDB 像拍照，快速但有间隔；AOF 像日记，详细但稍慢。文件格式上，RDB 是紧凑的二进制，AOF 是可读的命令日志。刷盘策略则决定了数据安全和性能的平衡。理解这些细节后，你可以根据业务需求选择合适的方案，甚至混合使用两者。

希望这篇分析让你对 Redis 持久化有了更深的认识！有什么疑问，欢迎讨论。