本文讲解Redis的持久化机制：RDB（快照）和AOF（日志）。深入对比二者在数据安全、恢复速度上的优劣，并介绍结合两者优点的混合持久化方案，以保障数据安全。

我们来详细、系统地讲解一下 Redis 的持久化机制。

为什么需要持久化？

Redis 是一个基于内存的数据库。所有的数据都存放在内存中，这使得它的读写速度非常快。但内存的缺点是，一旦服务器进程退出或服务器宕机，内存中的数据就会全部丢失。

为了解决这个问题，Redis 提供了持久化机制，即将内存中的数据以某种形式写入到磁盘中，确保在 Redis 重启后能够从磁盘中恢复数据，保证数据的安全性。

Redis 提供了两种主要的持久化方式：RDB (Redis Database) 和 AOF (Append-Only File)。

---

1. RDB (Redis Database) 持久化

RDB 是 Redis 默认的持久化方式。它会在指定的时间间隔内，生成一个当前内存数据的时间点快照（snapshot），并将其保存到一个名为 dump.rdb 的二进制文件中。

工作原理

RDB 的触发方式主要有三种：

1. 手动触发：

   • SAVE：该命令会阻塞 Redis 主进程，直到 RDB 文件创建完毕。在此期间，Redis 不能处理任何客户端请求。生产环境中应避免使用。
   • BGSAVE：该命令会创建一个子进程（fork）来负责生成 RDB 文件，主进程可以继续处理客户端请求，不会造成阻塞。这是最常用的方式。

2. 自动触发：
   在 redis.conf 配置文件中，通过 save 指令可以设置自动触发 BGSAVE 的条件。例如：

   plaintext

   # 表示在 900 秒内，如果至少有 1 个 key 发生了变化，就自动触发 BGSAVE
   save 900 1
   # 表示在 300 秒内，如果至少有 10 个 key 发生了变化，就自动触发 BGSAVE
   save 300 10
   # 表示在 60 秒内，如果至少有 10000 个 key 发生了变化，就自动触发 BGSAVE
   save 60 10000

   只要满足其中任意一个条件，Redis 就会自动执行 BGSAVE。

3. 其他情况：

   • 执行 SHUTDOWN 命令时，如果没有开启 AOF，Redis 会自动执行一次 BGSAVE。
   • 当 Redis 作为主服务器，从服务器发起全量同步时，主服务器会自动执行 BGSAVE 生成 RDB 文件并发送给从服务器。

BGSAVE 的核心流程

BGSAVE 使用了操作系统的 fork() 系统调用，并利用了 写时复制 (Copy-on-Write, CoW) 机制。

1. Fork 子进程：Redis 主进程调用 fork() 创建一个子进程。子进程拥有与父进程完全相同的内存数据副本。
2. 子进程写 RDB：子进程开始将内存中的数据写入到一个临时的 RDB 文件中。
3. 父进程继续服务：主进程（父进程）可以继续接收和处理客户端的请求。
4. 写时复制：如果在子进程写入 RDB 期间，主进程接收到了写操作（如 SET, DEL），操作系统会将被修改的内存页复制一份，让主进程在新复制的内存页上进行修改，而子进程继续读取旧的、未修改的内存页。这保证了数据的一致性，并大大减少了 fork() 带来的内存开销。
5. 替换文件：子进程完成 RDB 文件写入后，会用这个临时文件替换掉旧的 dump.rdb 文件，然后退出。

优点

• 性能好：由于 RDB 是通过子进程来完成的，对主进程的影响非常小，几乎不影响 Redis 的正常服务。
• 文件紧凑：dump.rdb 是一个经过压缩的二进制文件，体积小，非常适合用于备份、全量复制等场景。
• 恢复速度快：在重启时，Redis 只需直接加载 RDB 文件即可，反序列化速度远快于 AOF 文件的指令重放。

缺点

• 数据丢失风险高：RDB 是间隔性地进行快照，如果在上次快照之后、下次快照之前服务器发生故障，那么这期间所有修改的数据都会丢失。例如，你设置为 5 分钟一次快照，那么最坏情况下可能会丢失近 5 分钟的数据。
• 内存消耗：fork() 子进程会消耗额外的内存，尤其是在数据量巨大时，虽然有 CoW 机制，但在写入操作频繁的场景下，仍可能导致内存瞬间翻倍的风险。

---

2. AOF (Append-Only File) 持久化

AOF 以日志的形式，记录了 Redis 服务器接收到的每一条写命令（读命令不会被记录）。当 Redis 重启时，会重新执行 AOF 文件中保存的写命令，从而恢复数据。

工作原理

1. 开启 AOF：在 redis.conf 中设置 appendonly yes。开启后，Redis 执行的每一条写命令都会被追加到 AOF 文件（默认为 appendonly.aof）的末尾。

2. fsync 同步策略：
   AOF 数据是先写入到内核缓冲区，然后由内核决定何时刷写（sync）到磁盘。Redis 提供了三种同步策略，通过 appendfsync 配置项控制：

   • always：每执行一条写命令，就立即同步到磁盘。数据最安全，几乎不丢数据，但性能最差，因为磁盘 I/O 非常频繁。
   • everysec（默认）：每秒钟同步一次。这是一个很好的折中方案，性能较好，且最多只会丢失 1 秒的数据。
   • no：完全交由操作系统来决定何时同步。性能最好，但数据安全性最差，宕机时丢失的数据量不确定。

3. AOF 重写 (Rewrite)：
   随着时间推移，AOF 文件会越来越大，因为它记录了所有历史写操作。这不仅会占用大量磁盘空间，也会导致恢复速度变慢。为此，Redis 提供了 AOF 重写机制。

   • 原理：AOF 重写并不是读取旧的 AOF 文件进行分析，而是直接读取当前内存中的数据，然后用一条条命令来重新构建一个新的、更紧凑的 AOF 文件。例如，对一个计数器执行了 100 次 INCR，旧 AOF 文件有 100 条记录，而重写后的新 AOF 文件可能只有一条 SET counter 100。
   • 触发方式：可以手动执行 BGREWRITEAOF 命令，也可以配置自动触发（例如，当 AOF 文件大小超过上次重写后大小的 100% 时）。
   • 过程：重写过程也是通过 fork() 子进程来完成的，不会阻塞主进程。

优点

• 数据安全性高：根据 fsync 策略，可以做到几乎不丢失数据（always）或最多只丢失 1 秒的数据（everysec）。
• 文件可读：AOF 文件是文本格式，内容清晰，易于理解和修复。

缺点

• 文件体积大：通常情况下，AOF 文件的大小会比 RDB 文件大。
• 恢复速度慢：数据恢复时需要逐条执行 AOF 文件中的命令，当文件很大时，恢复时间会比 RDB 长。
• 性能影响：根据 fsync 策略，AOF 的写入性能通常会比 RDB 差一些。

---

3. Redis 4.0+ 混合持久化

为了兼顾 RDB 和 AOF 的优点，Redis 4.0 引入了混合持久化。

• 开启方式：在 redis.conf 中设置 aof-use-rdb-preamble yes。
• 工作原理：当进行 AOF 重写时，新的 AOF 文件将不再是纯命令格式。它会首先将当前内存的数据以 RDB 的格式写入文件开头，然后将重写期间产生的增量写命令以 AOF 的格式追加在文件末尾。
• 优点：
  • 恢复速度快：加载时，先像 RDB 一样快速加载前半部分的快照数据，然后再重放后半部分的增量 AOF 命令。这极大地提升了恢复速度。
  • 数据安全性高：保留了 AOF 的高数据安全性。

---

如何选择持久化策略？

实践建议：

1. 如果能容忍少量数据丢失（几分钟）：可以单独使用 RDB。它简单、高效，适合做冷备份。

2. 如果追求数据的最高完整性：必须使用 AOF。将 appendfsync 设置为 everysec 或 always。

3. 推荐的通用方案（Redis 4.0+）：

   • 同时开启 RDB 和 AOF。
   • 开启混合持久化 (aof-use-rdb-preamble yes)。

   这样组合的好处是：

   • AOF 负责保证数据的最终一致性和高可用性。
   • RDB 可以作为一个非常方便的备份工具，用于定期（如每天）的数据备份和归档。
   • 当 Redis 重启时，如果开启了 AOF，它会优先使用 AOF 文件（包括混合持久化格式的 AOF）来恢复数据，因为它通常包含更完整的数据。

这个组合策略，既利用了 AOF 的高数据安全性，又通过混合持久化解决了 AOF 恢复慢的问题，同时 RDB 文件还可以继续用于方便的备份，是目前最推荐的持久化方案。