详解 Redis AOF 重写过程中的双写机制

在 Redis 的持久化机制中，AOF（Append Only File）通过记录每一条写命令来保证数据的安全性。然而，随着运行时间的增加，AOF 文件会变得越来越大。为了解决这个问题，Redis 引入了 AOF 重写机制（BGREWRITEAOF）。

在 AOF 重写期间，Redis 需要同时处理客户端的写请求。为了防止数据丢失，Redis 采用了精妙的“双写”机制。本文将深入探讨 AOF 缓冲区与 AOF 重写缓冲区的作用及其重要性。

1. 为什么需要重写？

AOF 文件记录的是操作命令。例如，对同一个 Key 执行 100 次 INCR，AOF 会记录 100 条指令，但其实际效果等同于 1 条 SET 指令。重写机制就是通过读取当前数据库的状态，生成一份最小化的指令集来替换旧的 AOF 文件。

2. 重写期间的“双写”挑战

当 Redis 触发 BGREWRITEAOF 时，会 fork 出一个子进程来完成重写工作。

• 子进程：负责将此时此刻的数据库快照写入新的 AOF 文件。
• 父进程：继续处理客户端请求。

关键问题在于：子进程在重写期间，父进程新接收到的指令该往哪放？

2.1 AOF 缓冲区 (AOF Buffer)

父进程接收到的写指令会照常写入 AOF 缓冲区。这些指令会被定期同步到 旧的 AOF 文件。

为什么要写旧文件？
这是为了防止在重写期间 Redis 突然宕机。如果重写还没完成（新 AOF 文件不完整），Redis 重启时仍然可以依靠旧的、包含了最新指令的 AOF 文件来恢复数据，确保零丢失。

2.2 AOF 重写缓冲区 (AOF Rewrite Buffer)

同时，父进程会将这些新指令也写入一份到 AOF 重写缓冲区。

它的作用是什么？
当子进程完成快照写入并退出后，父进程会将这个重写缓冲区中的内容追加到 新的 AOF 文件 中。这样，新 AOF 文件就追平了重写期间发生的所有变更。最后，用新 AOF 文件原子替换旧文件。

3. 核心总结：防止数据丢失的盾牌

用户提到的“宕机导致丢失”正是这套机制要解决的核心痛点。

如果没有 AOF 缓冲区（即不写旧文件）：

• 场景：重写执行到 50%，服务器宕机。
• 结果：新 AOF 文件未产生，旧 AOF 文件缺失了重写期间产生的 50% 时间段内的写操作。重启后数据严重丢失。

有了“双写”：

• 场景：重写期间宕机。
• 结果：新 AOF 虽然丢了，但旧 AOF 文件依然保持着最新的完整记录（因为 AOF 缓冲区一直在工作）。这才是 Redis 高可靠性的体现。

注意：在 Redis 7.0 之后，引入了 Multi-Part AOF 机制，通过 Base + Incremental 文件的方式解决了重写缓冲区占用过度内存的问题，但其核心逻辑（保留增量修改以防丢失）依然一脉相承。