Redis 提供了两种关键的持久化机制：RDB 和 AOF。从 Redis 4.0 开始，还引入了混合持久化的概念，将两者结合使用。
1. RDB (Redis Database)
RDB 持久化是在指定的时间间隔内，生成内存中整个数据集的一个快照（Snapshot），并将其保存到一个二进制文件（默认名为 dump.rdb）中。
工作原理
- 创建快照：Redis 会 fork 一个子进程。
- 数据写入：子进程将当前内存中的所有数据写入一个临时的 RDB 记录。
- 替换旧文件：当子进程完成写文件后，会用新的 RDB 文件替换旧的 RDB 文档。
触发方式
- 手动触发：
SAVE命令：同步执行，会阻塞所有来自客户端的请求，直到快照完成。生产环境不建议利用。BGSAVE命令：异步执行，Redis 会 fork 子进程来创建快照，主进程继续处理命令。推荐使用。
- 自动触发：在
redis.conf配置文件中设置 save 规则。bash复制代码
save 900 1 # 在900秒（15分钟）内，如果至少有1个key发生变化，则触发bgsave save 300 10 # 在300秒（5分钟）内，如果至少有10个key发生变化，则触发bgsave save 60 10000 # 在60秒内，如果至少有10000个key发生变化，则触发bgsave
优点
- 性能高：RDB 文档是紧凑的二进制资料，非常适合用于备份、灾难恢复和全量复制。
- 恢复速度快：重启 Redis 时，恢复大数据集的速度远快于 AOF。
- 最大化性能：父进程无需进行任何磁盘 I/O 操作，由子进程完成。
缺点
- 数据安全性低：容易丢失数据。因为它是定时执行的，如果 Redis 在两次快照之间宕机，则会丢失最终一次快照之后的所有数据。
- fork 可能阻塞：虽然
BGSAVE是异步的，但 fork 子进程的过程，如果数据集非常大，可能会导致主进程短暂阻塞（毫秒级）。
2. AOF (Append Only File)
AOF 持久化会记录每一个对数据库进行写操作的命令，并将这些命令追加到一个日志文档的末尾。当 Redis 重启时，会重新执行 AOF 文件中的所有命令来重建数据。
工作原理
- 命令追加：每执行一个写命令，Redis 会将其以 Redis 协议格式追加到
aof_buf缓冲区。 - 文件写入与同步：根据设置的同步策略，将缓冲区的内容写入和同步到 AOF 磁盘文件。
同步策略 (appendfsync)
在 redis.conf 中通过 appendfsync 选项配置，这是影响性能和数据安全性的关键。
- no：由操作系统决定何时同步。写入最快，但数据安全性最差，宕机时可能丢失一个同步周期内的内容。
- everysec：默认推荐。每秒同步一次。是性能和内容安全性的良好折衷，最多丢失1秒的数据。
- always：每执行一个写命令就同步一次。信息最安全，但性能最差，因为每个命令都会进行磁盘 I/O，大大降低了 Redis 的速度。
AOF 重写 (Rewrite)
随着写操作的增多，AOF 文件会变得越来越大。Redis 提供了 BGREWRITEAOF 命令（或自动触发）来重写 AOF 文件。
- 原理：fork 一个子进程，根据当前数据库状态创建新的 AOF 文件。它会读取所有键值对，然后用一条命令（如
SET）记录一个键的当前值，从而消除冗余命令（如多个INCR），使文件体积最小化。
优点
- 数据安全性高：根据
appendfsync配置，最多只会丢失一秒的数据，甚至完全不丢失。 - 可读性强：AOF 文件是纯文本格式，记录了所有操作命令，便于理解和分析。
缺点
- 文件体积大：通常 AOF 资料会比同数据的 RDB 文件大。
- 恢复速度慢：恢复数据时需要重新执行所有命令，比 RDB 慢。
- 性能影响：在写操作频繁且配置为
always策略时，对性能影响较大。
3. 混合持久化 (RDB + AOF)
这是 Redis 4.0 引入的机制，结合了 RDB 和 AOF 的优点。
工作原理
- 在 AOF 重写时，子进程不再是单纯地将命令写入新的 AOF 文件，而是先将当前数据集以 RDB 格式写入文件开头。
- 然后，再将重写缓冲区的增量命令（以 AOF 格式）追加到 RDB 信息后面。
- 生成的新文件是一个前半部分是 RDB 快照，后半部分是增量 AOF 日志的混合文件。
优点
- 结合两者优点：重启时，先加载 RDB 部分的内容（速度快），再重放增量 AOF 命令（数据新），使得重启效率大幅提升。
- 数据更安全：同时拥有 AOF 的实时持久化特性。
启用方式：在 redis.conf 中设置 aof-use-rdb-preamble yes（默认已是 yes）。
总结与选择建议
| 特性 | RDB | AOF |
|---|---|---|
| 数据格式 | 二进制压缩快照 | 文本协议写命令日志 |
| 数据安全性 | 低，可能丢失分钟级素材 | 高，根据配置最多丢失1秒数据 |
| 文件体积 | 小 | 大（但可重写优化） |
| 恢复速度 | 快 | 慢 |
| 性能影响 | fork 时短暂阻塞 | 写入频繁时对性能有影响（取决于同步策略） |
生产环境建议：
- 单纯使用 RDB：如果你希望获得最佳性能，并且能够容忍分钟级别的材料丢失（如用于缓存），可以只使用 RDB。
- 单纯使用 AOF：如果你对数据安全性要求极高，不允许任何数据丢失（如存储重要状态），并且可以接受稍慢一点的性能，可以只使用 AOF（配置为
appendfsync everysec）。 - 混合持久化（推荐）：这是目前最主流和推荐的方式。它提供了快速的恢复速度和良好的数据安全性，在性能和可靠性之间取得了最佳平衡。只需同时开启 RDB 和 AOF 即可（
appendonly yes+aof-use-rdb-preamble yes）。
最重要的建议：无论使用哪种策略，定期将 RDB 或 AOF 文件备份到异地机房或云存储上，以防物理灾难。