单机多实例RDB互相卡住，是因为默认save 900 1导致各实例在相近时间触发bgsave，引发fork开销叠加和磁盘IO争抢；应通过错开save时间窗口（如840/960/1020秒）、分组配置或禁用RDB启用AOF来解决。
为什么单机多实例的RDB会互相卡住
多个Redis实例共用一台物理机时，如果都配置了默认的 save 900 1，它们大概率会在相近时间触发 bgsave。虽然每个 bgsave 是子进程异步执行，但 fork() 时需复制主进程页表、申请内存映射，高内存占用下会引发显著延迟；更关键的是，多个子进程同时写磁盘（尤其是机械盘或共享IO的云盘），会造成IO争抢，导致所有实例响应变慢甚至超时。
如何错开各实例的RDB触发时间点
核心思路是让每个实例的 save 规则在时间窗口上错开，避免周期性重叠。不依赖统一调度，而是靠配置隔离：
- 不要所有实例都用
save 900 1—— 改成不同组合，例如：save 840 1、save 960 1、save 1020 1 - 若实例数较多（如6个），可分组设置：第1/3/5个用
save 900 1，第2/4/6个用save 1800 1，再配合启动时间偏移 - 用
redis-cli -p动态修改（需确保config set save "..." config rewrite后落盘） - 绝对不要在 conf 中留空
save行——save ""是禁用RDB，不是“不配置”
哪些场景下必须禁用RDB而只用AOF
当单机部署 >8 个 Redis 实例，且机器内存 ≥64GB、磁盘为共享云盘（如腾讯云CBS、阿里云ESSD AutoPL）时，RDB fork 开销和IO毛刺已不可控。此时应统一关闭RDB，仅启用AOF，并调优其同步策略：
- 设
appendonly yes，appendfsync everysec（默认值，平衡安全与性能） - 禁用
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size的自动重写，改用定时脚本在低峰期手动触发bgrewriteaof - 确保
aof-rewrite-incremental-fsync yes（默认开启），减少重写时的IO峰值 - 注意：AOF文件体积增长快，需定期
redis-cli -p清理，否则可能触发bgrewriteaof maxmemory淘汰或写阻塞
验证错峰是否生效的实操方法
不能只看配置，要确认实际触发时间是否分散：
- 查每个实例的最近RDB时间：
redis-cli -pinfo persistence | grep -E "rdb_last_save|rdb_bgsave_in_progress" - 用
ps aux | grep 'redis.*bgsave'看当前是否有多个bgsave子进程并存 - 监控
redis_rdb_changes_since_last_save指标（通过INFO或 Prometheus exporter），观察各实例的写入累积曲线是否错峰抬升 - 最直接的方式：在凌晨2点手动
redis-cli -p后，立刻对其他端口执行，看是否出现bgsave ERR Background save already in progress—— 如果没有，说明错峰配置已起效
真正难的不是配参数，而是意识到：单机多实例不是简单复制配置就能跑稳的。每个 bgsave 都在争夺 fork 资源和磁盘带宽，而这个代价在线上抖动里往往被归因为“网络问题”或“应用层慢”，没人去翻 INFO persistence 里的 rdb_last_bgsave_status 字段。
