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