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 写速）时，哪怕调大间隔也压不住延迟，得先换盘或降实例内存大小。
