主从同步触发网络风暴的根源是多个从节点集中发起全量复制，导致主节点cpu、内存和带宽被瞬间打爆；典型场景包括哨兵故障转移、批量扩容未错峰、主节点重启后争抢同步，叠加bgsave和rdb分发引发fork阻塞、延迟飙升甚至oom。

为什么主从同步会触发网络风暴

主从同步本身不“风暴”，但多个从节点在特定时机集中发起全量复制，就会瞬间打爆主节点的CPU、内存和带宽。典型场景包括：哨兵故障转移后新主节点刚上位，所有从节点发现replicaof目标变了，立刻重连并请求PSYNC；或批量扩容从节点时未错峰启动；又或者主节点重启后，所有从节点同时检测到连接断开，争抢同步。此时主节点反复执行bgsave，每个从节点都接收一份完整RDB文件（可能上百MB），叠加repl_buffer命令重发，极易造成主节点fork阻塞、延迟飙升甚至OOM。

用repl-backlog-size和repl-backlog-ttl控制增量同步窗口

Redis默认的repl-backlog-size只有1MB，对中高写入量的实例远远不够。一旦从节点断线时间稍长，或断线期间主节点写入量超过缓冲区容量，就会强制退化为全量同步——这是风暴最常见诱因。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 把repl-backlog-size设为写入流量的2–3倍：例如主节点QPS 5k、平均命令大小200B，每秒写入约1MB，则建议设为repl-backlog-size 10485760（10MB）
• 配合repl-backlog-ttl避免长期空转：设为3600（1小时），缓冲区在无从节点连接时自动释放内存
• 必须在主节点配置文件中设置，从节点无需配；修改后需重启主节点才生效

避免多从节点同时重连：用slave-priority和错峰启动策略

哨兵选主后，所有从节点默认立即向新主发起同步，毫无节制。虽然Redis 5.0+已支持“主节点只做一次bgsave分发多份”，但网络传输仍并行，压力不减。关键在于让从节点“排队”而非“抢跑”。

• 给不同从节点配置差异化slave-priority（如10、20、30），哨兵在故障转移时会按优先级排序候选节点，但更重要的是：低优先级从节点在检测到主变更后，会延迟几秒再发起PSYNC，这个延迟由哨兵内部实现，无需额外配置
• 运维侧主动错峰：批量部署从节点时，用脚本控制启动间隔，例如sleep $((RANDOM % 30))后再redis-server
• 禁用replica-announce-ip和replica-announce-port以外的冗余配置，防止从节点因地址解析失败反复重试

监控与告警必须盯住master_repl_offset和slave_repl_offset差值

网络风暴发生前，往往先有持续扩大的复制延迟。光看INFO replication里的lag字段不可靠（它只反映心跳延迟），真正有效的是偏移量差值。

• 定期采集主节点的master_repl_offset和各从节点的slave_repl_offset，差值超过100万就预警
• 差值突增+主节点used_memory_rss飙升+instantaneous_ops_per_sec骤降，基本可判定正在发生全量同步风暴
• 不要依赖哨兵自身的sentinel masters输出判断同步状态——它不暴露偏移量，只显示is-connected:yes这种表层信息

真实压测中见过最狠的一次：6个从节点在主节点恢复后1.2秒内全部重连，主节点bgsave耗时从800ms飙到4.3s，repl_buffer峰值占满1.2GB内存，导致后续写请求超时。防御不在架构多炫，而在把repl-backlog-size调够、把启动节奏控住、把偏移量差值当核心指标盯死——这些地方一松，风暴就不是“可能”，而是“必然”。