1.1 触发机制#

1
save 900 1    # 900秒内至少1个key变化
2
save 300 10   # 300秒内至少10个key变化
3
save 60 10000 # 60秒内至少10000个key变化

1.2 底层原理：Fork 与 Copy-on-Write (CoW)#

很多同学不理解：为什么 BGSAVE 不阻塞主线程？如果主线程还在写数据，快照怎么保证数据一致性？

这里用到了操作系统的 写时复制 (Copy-on-Write, CoW) 机制。

1. Fork 子进程：Redis 父进程调用 fork() 系统调用创建子进程。
   • 阻塞点：fork() 本身是阻塞的，耗时取决于页表（Page Table）的大小（即内存大小）。如果 Redis 占用了 10GB 内存，Fork 可能需要几百毫秒。
2. 共享内存：Fork 后，父子进程共享同一段物理内存。子进程开始读取内存数据并写入 RDB 文件。
3. CoW 发生：在此期间，如果父进程接收到了新的 写命令（修改 Key A），操作系统不会直接修改共享内存，而是将 Key A 所在的 内存页 (Page) 复制一份给父进程修改。
   • 子进程看到的依然是 Key A 的旧值（快照时刻的值）。
   • 父进程修改的是新副本。

性能隐患：如果 RDB 期间写流量极大，会导致大量的内存页复制，甚至导致内存占用瞬间翻倍（OOM 风险）。

1.3 RDB 的优缺点#

• 优势：
  • 文件紧凑（二进制压缩），适合备份和灾难恢复。
  • 加载速度快（直接反序列化）。
• 劣势：
  • 数据丢失：间隔（如 5 分钟）内的变更会丢失。
  • CPU/内存消耗：Fork 操作属于重型操作。

2.1 写入流程#

1. 命令追加：写命令执行完后，先追加到 aof_buf 内存缓冲区。
2. 文件写入：调用 write() 将缓冲区数据写入内核缓冲区。
3. 文件同步：调用 fsync() 将内核缓冲区数据刷入磁盘（这是最关键的一步）。

2.2 同步策略 (appendfsync)#

• always：每条命令都 fsync。
  • 安全：最多丢一条命令。
  • 性能：极差（转变为 IO 密集型）。
• everysec（默认）：每秒 fsync 一次。
  • 折中：最多丢 1 秒数据，性能损耗小。
• no：不主动 fsync，由操作系统决定（通常 30秒）。
  • 性能：最好。
  • 风险：宕机丢失大量数据。

2.3 AOF 重写 (Rewrite)#

随着时间推移，AOF 文件会越来越大。比如你对 count 加了 100 次，AOF 里就有 100 条 INCR 命令，但恢复时只需要 SET count 100 一条。

Redis 通过 BGREWRITEAOF 触发重写：

1. Fork 子进程。
2. 子进程遍历内存，构造重构后的 AOF 文件。
3. AOF 重写缓冲区：在子进程重写期间，父进程收到的新写命令，不仅要写入旧 AOF，还要写入 AOF 重写缓冲区。
4. 子进程写完后，父进程将重写缓冲区的数据追加到新文件，并替换旧文件。