parallel-syncs 是 Redis 主从复制中限制同时发起全量同步的从库数量的参数，设为0将禁用防护、生产环境严禁；其值需根据主库内存峰值和从库数谨慎设定，否则易引发 OOM 或延迟毛刺。
parallel-syncs 是什么，改它真能防雪崩？
parallel-syncs 是 Redis 主从复制中一个被严重低估的保命参数——它不控制同步速度，只管“同时有几个从库能连上来做全量同步”。主库故障后，所有从库发现失联，会集体发起 SYNC 或 PSYNC 请求；若不设限，十几台从库瞬间涌进来，主库 CPU、内存、网络带宽直接打满，新主可能自己先挂掉。
这个参数生效的前提是：主库已切换完成（比如通过哨兵或 Cluster 自动选主），且从库正处于尝试建立复制连接的阶段。它对已经连上并处于增量同步（REPLCONF ACK）的从库完全没影响。
-
parallel-syncs默认值是1，非常保守，但多数中小规模部署其实可以适当调高 - 值设为
0表示“不限制”，等于主动放弃防护，生产环境严禁 - 它只作用于主节点配置，从节点无需配，也不认这个参数
怎么设才安全？看主库扛不扛得住 fork
全量同步本质是主库 fork() 出子进程做 RDB 快照，而 fork() 的开销和当前主库内存使用量强相关。如果主库用了 16GB 内存，parallel-syncs 设成 3，就意味最多 3 个子进程同时 fork，瞬间申请近 48GB 虚拟内存（Linux copy-on-write 机制下，页表先全量复制），极易触发 OOM Killer 杀掉 redis-server。
- 用
info memory查used_memory_peak_human，按峰值内存的 1.2 倍估算 fork 压力 - 单次
fork在 SSD 上通常耗时 100–500ms，期间主库响应延迟明显升高；并发 fork 会让延迟毛刺更密、更长 - 建议初始值 =
min(从库总数 ÷ 2, 3)，再观察latest_fork_usec和evicted_keys是否突增
为什么改了没效果？常见失效场景
改完 parallel-syncs 却发现从库还是扎堆连，大概率掉进了这几个坑：
- 没用
CONFIG REWRITE或没重启 Redis，修改只在运行时生效，但哨兵/Cluster 故障转移时会重新加载配置文件，旧值复活 - 用了 Redis 5.0 之前的版本，
parallel-syncs对PSYNC2不生效，老版本只限制首次全量，不控后续部分重同步 - 从库配置了
replica-serve-stale-data no，一断连就立刻退出服务，根本等不到主库恢复和同步启动 - 网络中间件（如代理、LB）做了连接复用，让多个从库的 SYNC 请求看起来像同一个客户端发的，绕过了计数逻辑
配合哪些参数一起调，才算真正稳住
parallel-syncs 单独调就像只系安全带不踩刹车——得搭配其他复制控制参数才能形成缓冲带：
-
repl-timeout 60：避免从库因短暂抖动反复断连重试，减少无效 SYNC 次数 -
repl-backlog-size 10485760（10MB）：增大复制积压缓冲区，让更多从库能走PSYNC增量同步，跳过全量 -
repl-diskless-sync yes+repl-diskless-sync-delay 5：启用无盘同步，省掉写 RDB 到磁盘的 IO，降低 fork 后子进程的落地压力（但要求从库也支持 diskless）
真正麻烦的是混合部署：有些从库是 Redis 4.x，有些是 7.x，parallel-syncs 的行为边界会变得模糊。这种时候，宁可保守点，把值锁死在 2，再靠监控 sync_full 和 sync_partial_ok 的比例来判断是否值得放开。
