完整教程：Redis 提供了两种主要的持久化机制：RDB 和 AOF

Redis 提供了两种关键的持久化机制：RDB 和 AOF。从 Redis 4.0 开始，还引入了混合持久化的概念，将两者结合使用。

---

1. RDB (Redis Database)

RDB 持久化是在指定的时间间隔内，生成内存中整个数据集的一个快照（Snapshot），并将其保存到一个二进制文件（默认名为 dump.rdb）中。

工作原理

1. 创建快照：Redis 会 fork 一个子进程。
2. 数据写入：子进程将当前内存中的所有数据写入一个临时的 RDB 记录。
3. 替换旧文件：当子进程完成写文件后，会用新的 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 文件中的所有命令来重建数据。

工作原理

1. 命令追加：每执行一个写命令，Redis 会将其以 Redis 协议格式追加到 aof_buf 缓冲区。
2. 文件写入与同步：根据设置的同步策略，将缓冲区的内容写入和同步到 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 时短暂阻塞	写入频繁时对性能有影响（取决于同步策略）

生产环境建议：

1. 单纯使用 RDB：如果你希望获得最佳性能，并且能够容忍分钟级别的材料丢失（如用于缓存），可以只使用 RDB。
2. 单纯使用 AOF：如果你对数据安全性要求极高，不允许任何数据丢失（如存储重要状态），并且可以接受稍慢一点的性能，可以只使用 AOF（配置为 appendfsync everysec）。
3. 混合持久化（推荐）：这是目前最主流和推荐的方式。它提供了快速的恢复速度和良好的数据安全性，在性能和可靠性之间取得了最佳平衡。只需同时开启 RDB 和 AOF 即可（appendonly yes + aof-use-rdb-preamble yes）。

最重要的建议：无论使用哪种策略，定期将 RDB 或 AOF 文件备份到异地机房或云存储上，以防物理灾难。