quorum不能设为1，因为会导致单个哨兵即可判定主节点下线，网络抖动时易误触发故障转移，引发服务中断；推荐设为哨兵数÷2+1的多数派值，兼顾容错与及时性。
sentinel monitor 的 quorum 值为什么不能设为 1
quorum 决定多少个哨兵达成一致才触发故障转移，设为 1 意味着单个哨兵就能判定主节点下线 —— 这会极大增加误判风险。比如网络抖动导致一个哨兵短暂失联主节点，它就可能发起不必要的切换，造成服务中断。
实际部署中必须满足：quorum ≤ 哨兵总数，且推荐设为「哨兵数 // 2 + 1」（即多数派）。例如部署 3 个哨兵，sentinel monitor mymaster 192.168.1.101 6379 2 是合理值；5 个哨兵则用 3。
- quorum 太小 → 容易脑裂、频繁切换
- quorum 太大 → 主节点真挂了却无法及时转移（比如 3 哨兵设成
3，其中 1 个宕机，剩下 2 个永远凑不够 3 票） - quorum 不影响主观下线（每个哨兵独立判断），只控制客观下线和后续投票流程
down-after-milliseconds 设太短会怎样
sentinel down-after-milliseconds 是哨兵判定主节点“主观下线”的超时阈值。设得太短（比如 1000），在高延迟或瞬时网络波动时，哨兵会频繁认为主节点不可达，进而反复触发选举 —— 你看到的现象可能是：主节点明明活着，但从节点却在几秒内被轮番提拔又降级。
生产环境建议从 5000 起步（5 秒），再根据实际 RTT 和业务容忍度微调。若 Redis 实例部署在跨可用区网络中，应设为平均 ping 延迟的 3–5 倍。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 该参数对所有被监控节点（主+从）生效
- 它不等于故障转移耗时，只是“开始怀疑”的起点
- 修改后需重启哨兵或执行
SENTINEL CONFIG SET生效（Redis 7.0+ 支持热更新）
parallel-syncs 控制什么，为什么不能设太高
sentinel parallel-syncs 决定故障转移后，有多少个从节点能并发地向新主同步数据。设太高（比如 10）会导致新主瞬间承受大量 RDB 生成 + 网络传输压力，CPU 和带宽打满，甚至触发 OOM 或连接拒绝。
默认是 1，保守但安全；线上可按从节点数和主节点负载能力设为 2 或 3。注意：这个值只在 failover 阶段生效，日常主从复制不受影响。
- 值为
0表示禁止并行同步（全部串行），极端场景下用于保主节点稳定 - 它和
repl-backlog-size配合使用 —— backlog 太小 + parallel-syncs 太大，容易导致部分从节点全量重同步 - Redis 7.0 对 RDB 生成做了优化，但并发同步仍建议不超过主节点 CPU 核数的一半
failover-timeout 必须大于 down-after-milliseconds 吗
不是必须，但强烈建议。因为 sentinel failover-timeout 是整个故障转移流程的总时限（包括选主、同步、配置传播等），而 down-after-milliseconds 只是其中第一步的判定窗口。如果后者比前者还大，哨兵可能还没来得及确认主节点下线，整个 failover 流程就已超时中止。
典型组合：down-after-milliseconds 5000 + failover-timeout 60000（1 分钟）。Redis 7.0 默认值已是该比例，除非你有特殊调度逻辑，否则不要反向设置。
- 该超时也约束从节点升级后的配置传播等待时间
- 超时后哨兵会放弃本次 failover，但不会回滚已做的操作（比如已提升的从节点仍保持主身份）
- 若集群规模大、网络延迟高，可适当放宽到 120000，但需同步检查客户端重连逻辑是否扛得住
