rdb导致的io等待本质是bgsave子进程fork后短时高压写盘，需联动redis日志（如“background saving started”）与iostat的wkb/s突增归零特征来确认，而非仅依赖%util或w_await。

Redis RDB 导致的频繁磁盘 IO 等待，本质是 bgsave 子进程在 fork 后持续写入大文件，而磁盘吞吐跟不上。直接看 iostat -x 1 的 %util 和 w_await 没用——得联动 Redis 日志和状态指标才能准确定位。

怎么确认是 RDB 而不是 AOF 在刷盘

只靠 iostat 容易误判。RDB 和 AOF rewrite 的 IO 模式完全不同：

• RDB 是“短时高压”：iostat 会看到几秒内 wkB/s 拉满（比如 80MB/s），然后瞬间归零；对应 Redis 日志出现 Background saving started by pid 和 Background saving terminated with success
• AOF rewrite 是“中时长稳定写”：wkB/s 波动小但持续高位（比如 15–25MB/s）几十秒到几分钟；日志出现 Starting automatic rewriting of AOF
• 执行 redis-cli config get save，如果返回 save "" 或空数组，说明 RDB 已禁用，那所有 IO 尖峰都来自 AOF

为什么改 save 配置能立刻缓解 IO 峰值

RDB 触发完全由 save 配置行驱动，不是定时轮询。每次写操作都会累加变更计数器，只要没满足任一 save x y 条件（x 秒内 y 次变更），就不会 fork、不会写磁盘。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 默认 save 900 1 意味着：只要 15 分钟内任意 key 被改一次，就触发 bgsave —— 高频写场景下几乎等同于“每改就存”
• 改成 save 300 50000 后，必须 5 分钟 + 5 万次变更才触发，IO 峰值被大幅削平
• 别用 save "" 禁用 RDB，旧版本有兼容问题；注释掉整行更安全，比如 # save 900 1

改完配置不生效？三步必须做全

Redis 不热重载 save 行，改完 redis.conf 必须让新配置真正加载：

• 确认改的是当前实例加载的配置路径：redis-cli config get dir 和 config get dbfilename 交叉验证
• 执行 redis-cli config rewrite（仅限启用了 CONFIG REWRITE 权限的实例）
• 或稳妥重启：redis-cli shutdown save && redis-server /path/to/redis.conf

排查时最容易被忽略的点

很多人盯着 info Persistence 看 rdb_changes_since_last_save，却忘了查 info stats | grep changes_since_last_save —— 这个才是实时累计变更数。结合 uptime_in_seconds 反推平均每分钟变更量，才能判断你设的 save 300 50000 是不是真匹配业务节奏。磁盘本身慢（比如只有 3MB/s 写速）时，哪怕调大间隔也压不住延迟，得先换盘或降实例内存大小。