Redis 在生成 RDB 文件时如何处理请求？

标签：后端、Redis

🏛 业务架构师

RDB 生成期间 Redis 照常服务读写，机制是 fork + 写时复制（COW）：

bgsave 触发时主进程 fork 子进程——fork 后父子进程共享物理内存页；
子进程遍历内存把快照写盘，读的是 fork 瞬间的数据视图（一致性快照）；
期间主进程继续处理请求：写入时复制——某个内存页被修改，内核复制该页给主进程改，子进程仍看旧页——读服务不受影响，写性能有轻微开销。

业务视角，真正要管理的是两个代价：

fork 停顿：fork 本身要复制页表，实例内存越大停顿越久（10GB 约 100ms+，25GB 可达数百毫秒）——对 P99 敏感的交易缓存，这个停顿就是周期性毛刺。对策：单实例内存控制在 10GB 内（这是内存上限的业务理由之一）、错峰触发（bgsave 避开大促高峰，用定时策略而不是自动触发）、大实例考虑关闭 RDB 用从库做快照；
内存水位翻倍风险：COW 意味着写密集期间父子页分离，额外内存消耗与写入量成正比——机器内存要留足余量（Redis maxmemory 建议 ≤ 机器内存的 50~60%），否则 fork 期间 OOM。

引申到架构权衡：快照的一致性（fork 视图）+ 服务的连续性（COW）用内存和瞬时停顿支付——这是"可用性换一致性成本"的又一个样本。生产配置上我会把"fork 耗时监控"（info stats 的 latest_fork_usec）纳入巡检——它悄悄上涨就是实例该拆的信号。

一句话：RDB 期间"服务不停、快照一致"，但fork 停顿与 COW 内存是隐性账单——容量规划时必须计入。

🏗 系统架构师

RDB 生成用 BGSAVE：fork 子进程做快照，主进程继续处理命令，靠**写时复制（COW）**保证一致性：

fork 瞬间：父子进程共享同一份物理内存页，子进程看到的是 fork 时刻的数据视图，快照一致性由此保证；
主进程继续写：某页被修改时，内核复制该页（copy-on-write），子进程仍读旧页写 RDB，主进程写新页——读写互不干扰；
代价：极端写入下 COW 复制的页越来越多，内存占用最多翻倍；fork 本身对大实例有百毫秒级停顿（复制页表）；磁盘 IO 压力。

所以答案是：请求不会被阻塞（除 fork 瞬间的短暂停顿与 COW 内存放大），这是"快照期间可用"的机制根源。

生产关注点：

内存水位控制：maxmemory ≤ 物理内存 50~60%，给 COW 留余量，否则快照期间被 OOM Killer 干掉；
fork 停顿监控：info stats 的 latest_fork_usec，大实例考虑关透明大页（THP）、用物理机部署；
磁盘满是常见事故：RDB/AOF 目录磁盘独立监控；
从库做 RDB：全量同步时主库 BGSAVE 生成 RDB 传从库，同步期间主库写压力要评估；
无法容忍分钟级数据丢失的话，RDB 之外叠加 AOF（everysec）或混合持久化。

💻 全栈开发专家

BGSAVE 期间主进程继续处理读写，靠 fork 的写时复制（Copy-On-Write）隔离：

text

1. 主进程 fork() 出子进程（fork 本身有短暂停顿，微秒~毫秒级，页表复制）
2. 子进程遍历内存把快照写 RDB 文件
3. 期间主进程照常处理请求：
   - 读：无影响
   - 写：修改某内存页时，内核复制该页给主进程改，子进程仍看到旧页（快照一致性）
4. 子进程写完通知主进程（aof/fsync 更新），主进程更新统计信息

关键工程影响（这才是考点）：

fork 停顿与内存正相关：info stats 的 latest_fork_usec 直接量化——内存越大，页表复制越久；10GB 实例 fork 可能上百毫秒，期间所有请求阻塞。控制单实例内存是根本，禁用 THP（透明大页会让 fork 和 COW 更糟）。
写时复制的内存放大：极端情况下 bgsave 期间所有页都被写，内存占用接近翻倍（子进程一份 + 主进程修改副本一份）。所以容量规划要留 50% 余量，否则 bgsave 触发系统 OOM killer，Redis 直接被杀——我见过线上"每次备份后 Redis 消失"的案例。
快照一致性 vs 丢数据窗口：RDB 只反映 fork 那一刻的数据，之后到下次备份之间的写会丢——所以不能只靠 RDB，要配 AOF（everysec 最多丢 1 秒）。

运维细节：自动触发 save 900 1（900 秒 1 次修改）低峰更友好；从库的全量同步也走 bgsave，从库重连风暴会造成连环 fork，控制从库数量和重连频率。