sentinel parallel-syncs仅在故障转移后从库向新主发起全量同步时生效，不作用于日常复制、psync2重同步或心跳；设为0禁用防护，生产严禁；需config rewrite持久化且redis 5.0+才完全支持，否则修改无效。
直接改 sentinel parallel-syncs 不生效，大概率是因为你没踩中它的生效边界条件。
为什么改了 sentinel parallel-syncs 却没效果
这个参数只在故障转移（failover）刚完成、从节点开始向新主节点发起全量同步（RDB 传输）时起作用。它不控制日常复制、部分重同步（PSYNC2）、心跳或 INFO 轮询。
- Redis 5.0 之前版本：该参数对 PSYNC2 的部分重同步完全无效，只限制首次全量同步并发数
- 配置未持久化：仅用
SENTINEL SET运行时修改，但哨兵重启或故障转移时会重新加载sentinel.conf，旧值复活 - 没执行
CONFIG REWRITE或没重启哨兵进程，导致磁盘配置仍是默认值（通常为 10） - 误以为它影响“同步带宽”或“复制延迟”——其实它只管“同时开几个 SYNC 连接”，不干预单个连接的传输速率或压缩行为
sentinel parallel-syncs 的真实作用场景
它解决的是 failover 后新主节点瞬间被大量从节点压垮的问题，典型出现在 3+ 从库、高写入负载、RDB 文件较大的集群中。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为
1：最保守，串行同步，新主压力最小，但从库恢复服务时间拉长 - 设为
3：平衡点，多数中小规模集群适用，兼顾新主负载与恢复速度 - 设为
0：禁止自动同步（危险！），所有从库需手动SLAVEOF，仅用于调试或特殊编排 - 超过
5需谨慎：若新主内存/网络/磁盘 I/O 已临界，可能触发 OOM 或超时失败
容易被忽略的依赖配置项
parallel-syncs 不是孤立参数，它和几个底层行为强耦合：
-
repl-diskless-sync yes（主节点）：开启无盘复制后，并发 SYNC 对磁盘压力下降，但 CPU 和网络压力上升，此时可适当提高parallel-syncs -
repl-timeout 60（主/从节点）：同步超时时间必须大于 RDB 生成 + 传输预期耗时，否则并发连接会被中断重试，反而加剧抖动 -
replica-serve-stale-data no（从节点）：如果从库断连后直接拒绝读请求，那它根本等不到故障转移完成，parallel-syncs就失去了作用对象 -
sentinel down-after-milliseconds：这个值太小会导致频繁误判 failover，让parallel-syncs被反复触发，放大风险
验证是否真正生效的实操方法
不能只看配置文件或 SENTINEL GET-MASTER-ADDR-BY-NAME，要观察 failover 瞬间的行为：
- 在新主节点上执行
redis-cli --stat，关注sync_full计数器在 1–2 秒内是否突增到你设定的数值 - 用
netstat -anp | grep :6379 | grep ESTABLISHED | wc -l查看新主的 ESTABLISHED 连接数峰值（注意排除客户端连接） - 查哨兵日志：
grep "Start processing SYNC request" /var/log/sentinel.log，看时间戳是否密集落在同一秒内 - 关键陷阱：日志里出现
Connection refused或timeout，说明新主已扛不住，并发数实际被内核或 Redis 自身限流，此时降parallel-syncs比调优网络更有效
真正难的不是设数字，而是判断“此刻新主能不能扛住这个并发”——它取决于 RDB 大小、网络吞吐、磁盘随机写能力，以及你愿不愿意为快速恢复牺牲一点稳定性。
