Redis RDB 快照导致延迟抖动怎么排查：fork 阶段、内存峰值与避让策略

线上 Redis 的 p99 延迟突然从 3ms 抬到 80ms，慢日志却没有明显增加，时间点刚好落在一次 BGSAVE 之后。遇到这种抖动，先别急着把 maxmemory 调大：RDB 生成会经历主进程 fork，子进程写盘期间还可能触发写时复制，真正的压力常常落在内存和页复制上。

先把延迟时间线和 RDB 事件对上

第一步是确认“抖动”和快照是否真的同一件事。记录应用侧 p95/p99、Redis 命令延迟、主机内存和快照开始结束时间，不要只凭监控曲线的肉眼重合下结论。

redis-cli INFO persistence | grep -E 'rdb_|loading|aof_'
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_rss_human|mem_fragmentation_ratio'
redis-cli SLOWLOG GET 20

重点看 rdb_bgsave_in_progress 是否在抖动窗口变成 1，rdb_last_bgsave_time_sec 是否异常拉长，以及 rdb_changes_since_last_save 是否在高写入时快速增长。如果三者没有时间关系，就先查网络、热 key 或客户端连接池，别把所有延迟都归因给 RDB。

fork 为什么会让主进程短暂卡顿

BGSAVE 会让 Redis 请求一个子进程负责生成 RDB，主进程继续处理命令。这个“继续处理”不等于 fork 没有成本：复制页表、进程调度和机器当前的内存压力都可能让 fork 阶段变长。数据集越大、内存页越分散，启动子进程的瞬时成本越值得关注。

更容易被忽略的是写时复制（Copy-on-Write）。子进程读取快照期间，主进程继续修改某个内存页，操作系统需要复制这页再让主进程写入。业务写入越密集，RDB 存活时间越长，额外 RSS 越可能持续上涨。

用三个数判断是 fork 还是写时复制

这里的判断是方向，不是单一阈值。用操作系统进程统计、Redis INFO 和应用延迟三条线交叉验证，证据才够支撑后续改调度。

处理步骤：先保留证据，再调整快照窗口

1. 记录快照前后的资源峰值

在一次可控的快照窗口内记录 used_memory、used_memory_rss、主机可用内存、swap 活动和写入 QPS。RDB 文件大小只能说明落盘结果，不能替代进程峰值；写时复制的成本发生在生成过程中。

2. 把自动保存和高写入时段错开

如果业务允许，先调整 save 规则或调度时间，让快照落在低写入窗口。改动前保存当前配置：

redis-cli CONFIG GET save
redis-cli CONFIG GET stop-writes-on-bgsave-error
redis-cli LASTSAVE

生产环境不要直接删除所有自动保存规则来“止血”。先在从节点或影子实例复现，确认延迟下降和内存峰值回落，再小范围修改主实例。

3. 检查磁盘与 fork 条件

RDB 子进程还会受到磁盘吞吐、文件系统空间和系统 overcommit 设置影响。磁盘写入慢会拉长快照寿命，间接扩大写时复制窗口；内存不足时，fork 失败或频繁重试则会把持久化问题变成可用性问题。

需要止血时怎么回滚

如果快照期间延迟已经影响请求，先停止新增的手工 BGSAVE，不要连续点击触发。确认当前是否已有快照在运行，再决定是否把自动保存临时移到低峰。任何修改都要保留原始 CONFIG GET save 输出和变更时间。

若必须暂时关闭某条自动保存规则，应同时确认 AOF、从节点或外部备份是否承担了恢复职责。RDB 和 AOF 不是简单的“开关替代”：回滚延迟配置不能悄悄牺牲现有恢复目标。恢复窗口后，再用一轮低写入压测验证快照和重启恢复链路。

告警确认与复盘清单

• 告警是否标出 RDB 开始、结束和耗时，而不是只报 Redis p99？
• 是否同时记录 fork 时长、RSS 峰值、系统可用内存和 swap？
• 快照失败时，是否能区分磁盘空间、权限、fork 失败和写时复制压力？
• 调整调度后，是否验证了恢复文件可读、从节点同步和业务延迟？

相关问题

RDB 文件变小了，是否代表快照压力一定下降？

不一定。压力还取决于 fork 成本、写时复制页数、磁盘速度和生成期间的写入量，文件大小只能作为其中一个线索。

可以把 RDB 快照改成业务低峰就彻底解决吗？

低峰调度通常有效，但如果主从共用高负载机器、磁盘本身很慢或数据集持续增长，仍需继续观察 fork 和 RSS 峰值。

发现 rdb_bgsave_in_progress 长时间为 1 怎么办？

先查快照子进程、磁盘写入、剩余空间和系统内存，不要重复发起 BGSAVE；确认失败原因后再按恢复目标选择重试、调度或回滚。

把判断变成固定动作

Redis RDB 抖动的排查顺序可以固定为“对齐时间线、区分 fork 与写时复制、记录内存峰值、错开写入窗口、验证恢复链路”。这样处理，既不会因为一次尖峰就误改持久化策略，也不会在内存压力已经积累时只盯着命令耗时。