RDB快照导致CPU飙高源于fork后COW机制在高频写入时触发大量页复制；应禁用主节点自动快照，改由从节点低峰期执行，并关闭rdbcompression、rdbchecksum等加重CPU的默认配置。

为什么RDB快照会让CPU突然飙高？

Redis 生成 RDB 快照时，主线程会 fork 出一个子进程执行 bgsave；虽然数据拷贝靠 Copy-On-Write（COW）机制延迟分配物理内存，但一旦父进程在快照期间大量修改数据（比如高频写入、过期键清理、rehash），就会触发大量页复制，导致 CPU 瞬间飙升。这不是“快照本身慢”，而是 fork 后的内存写放大效应。

常见错误现象包括：

• 每到整点或固定时间点，top 显示 redis 进程 CPU 使用率冲到 80%+，持续数秒至数十秒
• 主节点响应延迟毛刺明显（latency monitor 报告 command 或 fast-command 类型延迟突增）
• 监控看到 used_memory_peak_human 在快照前后剧烈波动

怎么让 RDB 不在高峰期执行？

核心思路：把自动触发时机从“固定时间窗口”改成“业务低峰 + 内存稳定期”，同时避免主节点承担持久化压力。

• 修改 redis.conf 中的 save 规则，彻底关闭自动快照（尤其主节点）：

  save ""

  
  （不是注释掉，是明确设为空字符串；否则默认的 save 60 10000 仍生效）

• 改用 从节点或专用备份节点 承担 RDB 任务：

  • 配置从节点开启 save，主节点禁用
  • 或使用定时脚本，在凌晨 2–4 点调用 redis-cli -h backup-node bgsave
  • 注意：确保从节点未启用 slave-read-only no，避免误写污染快照

• 如果必须主节点做快照（如无从节点架构），可手动调度并加保护：

  • 先检查当前负载：redis-cli info stats | grep instantaneous_ops_per_sec，确认 instantaneous_ops_per_sec
  • 再执行：redis-cli config set save "3600 1" 临时开启宽松规则，等条件满足后立即 config set save "" 关闭

哪些配置参数会悄悄加重 CPU 压力？

几个看似合理、实则危险的默认项：

• rdbcompression yes：启用 LZF 压缩，快照体积小但压缩过程吃 CPU；若磁盘空间充足，直接设为 no
• rdbchecksum yes：校验和计算增加约 10% CPU 开销；生产环境若已通过校验流程（如备份后 md5 校验），可关
• stop-writes-on-bgsave-error yes：虽保障数据安全，但一旦快照失败（如磁盘满），会直接阻断写入——这比 CPU 高更致命，建议设为 no 并配合监控告警

替代方案：AOF 重写也踩坑？

AOF 重写（bgrewriteaof）同样 fork 子进程，且需遍历全部键重写命令流，CPU 和内存开销不亚于 RDB。它和 RDB 不是二选一，而是叠加风险。

• 切忌同时开启 auto-aof-rewrite-percentage 和高频写入场景；例如设置 auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 64mb，可能每天触发多次重写
• 更稳妥的做法：关闭自动重写（auto-aof-rewrite-percentage 0），改用定时脚本在低峰期手动触发，并搭配 CONFIG SET aof-rewrite-incremental-fsync yes 减少 I/O 尖峰

真正难的不是选 RDB 还是 AOF，而是意识到：fork 的代价永远存在，唯一可控的是“谁来 fork”和“什么时候 fork”。运维脚本里多一行时间判断，比调优十个参数更管用。