根本原因是bgsave触发的fork+COW机制在高频写入下引发大量内存页复制；需显式配置save ""关闭自动快照、禁用rdbcompression/rdbchecksum、由从节点低峰期执行，并监控used_memory_rss与used_memory差值防swap。
会卡顿，而且不是“偶尔抖一下”，是可复现的 CPU 和延迟毛刺——根本原因不是快照本身慢，而是 bgsave 触发的 fork + 写时复制（COW）在高频写入下引发内存页大量复制。
为什么高频 RDB 会让 Redis 响应变慢？
Redis 主线程执行 bgsave 时会 fork 子进程，子进程初始共享父进程物理内存页；但只要主线程在快照过程中修改任意数据（比如写入、过期淘汰、rehash），内核就得为该页做 COW 拷贝。业务写入越频繁，COW 越多，CPU 瞬间打满，instantaneous_ops_per_sec 可能不降反升，但 latency 监控里 command 类型延迟会突增 50–200ms。
常见现象：
-
top显示redis-server进程 CPU 占用冲到 70%+，持续 3–10 秒 -
redis-cli --latency报告周期性尖峰，尤其在整点或每分钟固定时刻 -
info stats中rdb_last_bgsave_time_sec小于 60，说明快照太密
save 配置怎么改才真正生效？
很多人注释掉默认 save 行就以为关了，其实没用——Redis 会 fallback 到内置默认值 save 60 10000。必须显式设为空字符串：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 运行时关闭：
redis-cli config set save "" - 配置文件写死：
save ""（注意不是# save 60 10000） - 验证是否生效：
redis-cli config get save返回1) "save" 2) ""
别信“每 5 分钟一次”这种通用建议。生产环境建议按变更量而非时间设阈值，例如：save 3600 100000（1 小时内至少 10 万 key 变更才触发），或干脆只由从节点执行。
哪些默认配置会悄悄加重 CPU 压力？
这些选项看着安全，实则对性能敏感场景是隐形炸弹：
-
rdbcompression yes：LZF 压缩吃 CPU，磁盘空间够就直接关成no -
rdbchecksum yes：校验和计算增加约 10% CPU 开销，若备份后有独立 md5 校验流程，可关 -
stop-writes-on-bgsave-error yes：快照失败就停写，比 CPU 高更致命，建议设为no并配监控告警
真正容易被忽略的是 used_memory_rss 和 used_memory 的差值——如果前者远大于后者（比如 > 1.5x），说明系统已开始 swap，此时调任何 save 参数都只是延缓崩溃。
