RDB的save指令会拖慢Redis，因满足条件时需fork子进程执行快照，内存大、页表多时fork耗时显著；写入密集易引发“快照风暴”，导致主线程阻塞、延迟抖动、mem_fork_ratio超2.0。
为什么RDB的save指令会突然拖慢Redis
因为每次满足save配置条件（比如save 60 10000）时，Redis会fork一个子进程执行快照。fork在内存大、页表多的场景下耗时显著——latest_fork_usec监控值若持续超500ms，就说明fork本身已在阻塞主线程。更糟的是，如果写入密集，可能刚结束一次RDB，下一秒又触发，形成“快照风暴”。
- 高峰期每分钟触发多次RDB，
info persistence里rdb_last_bgsave_time_sec频繁跳变 - 客户端出现明显延迟抖动，
latency latest显示command或fast-command类型延迟突增 -
INFO memory中mem_fork_ratio接近或超过2.0（fork开销过大）
如何安全降低save触发频率
不是简单删掉save行，而是按业务容忍度重新建模：你最多能接受丢失多久的数据？这个时间窗口直接决定seconds参数下限。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 允许丢5分钟数据 → 改为
save 300 1（5分钟内任意1次变更即触发），比默认save 900 1更激进，但实际写入少时反而减少触发次数 - 写入极低频（如配置中心类服务）→ 只保留
save 3600 1，甚至注释掉所有save，改用定时BGSAVE脚本在凌晨执行 - 禁用自动RDB → 显式设
save ""（空字符串），完全交由运维手动控制快照时机 - 务必同步调整
stop-writes-on-bgsave-error yes，避免因磁盘满等故障导致写入静默失败
AOF重写和RDB快照撞车怎么办
当auto-aof-rewrite-percentage和save条件同时满足，两个后台子进程会并发争抢IO和CPU，redis-cli --stat能看到instantaneous_ops_per_sec断崖式下跌。
- 错峰配置：把AOF重写阈值调高（如
auto-aof-rewrite-percentage 200），并设auto-aof-rewrite-min-size 512mb避免小文件频繁重写 - 强制串行化：启用
aof-rewrite-incremental-fsync yes，让AOF重写过程分批刷盘，减轻单次IO压力 - 关键业务节点可关闭RDB，只留AOF +
appendfsync everysec，用bgrewriteaof替代bgsave作为唯一持久化手段
容易被忽略的系统级放大效应
即使save策略调得再保守，如果底层OS没优化，fork延迟仍可能失控。尤其在容器或云主机环境，cgroup内存限制、THP（透明大页）会成倍放大fork耗时。
- 必须禁用THP：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 确认
/proc/sys/vm/swappiness为0，防止fork时触发swap - SSD是硬需求——机械盘上
bgsave耗时可能从200ms飙到2s以上，且不可预测 - 监控不能只看
rdb_last_bgsave_status是否为ok，要盯住rdb_last_bgsave_time_sec和latest_fork_usec两个指标的趋势
