quorum设为1时，网络分区必然触发双主；因任意哨兵可单独判定主观下线并发起故障转移，分区后两边各自选举新主，导致数据分裂与丢失。
quorum设为1时，网络分区必然触发双主
当 sentinel monitor mymaster 127.0.0.1 6379 1 时，任意一个哨兵只要主观判定主节点下线，就可自行发起故障转移——它不需要等待其他哨兵确认。一旦发生网络分区，两边哨兵各自“失联”，又各自满足 quorum=1 条件，就会独立选出自己的 Leader 并各自提升一个从节点为新主。
常见错误现象：
- 客户端写入一半数据到旧主，一半到新主，恢复后旧主降级清空数据，造成不可逆丢失
- 日志里反复出现
+switch-master和+convert-to-slave交替记录
关键点：quorum 不是“投票总数”，而是触发客观下线的最小同意哨兵数；它必须 ≤ 哨兵总数的多数派（majority），否则选举无法收敛。
为什么3个哨兵配quorum=2是安全下限
3个哨兵构成最小多数派结构：majority = ⌊3/2⌋ + 1 = 2。此时 quorum=2 意味着至少两个哨兵达成共识才允许推进故障转移，天然防止单点误判和单边分区自作主张。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若部署5个哨兵，quorum 应设为3，而非2或5；设为2易受单哨兵抖动影响，设为5则丧失容错能力（任意1个哨兵宕机即无法 failover）
- 哨兵必须跨物理机/可用区部署，避免同一台机器上同时运行 master、slave 和多个 sentinel
- 检查所有哨兵配置中
sentinel monitor的 IP 和端口是否完全一致，不一致会导致部分哨兵监控错误实例
parallel-syncs 和 down-after-milliseconds 配合不当会加剧脑裂后果
down-after-milliseconds 控制主观下线阈值（默认30000ms），parallel-syncs 控制新主上任后允许多少从节点并发全量同步。二者看似无关，但存在隐性冲突：
- 若
down-after-milliseconds过小（如5000ms），网络抖动易触发误判，导致频繁故障转移 - 若
parallel-syncs过大（如设为10），新主在大量从节点同步期间压力陡增，可能超时触发二次 failover - 更危险的是：原主节点在网络恢复后尚未被降级，新主已开始接收写请求，而 parallel-syncs 尚未完成 —— 此时双主并存窗口被拉长
生产环境推荐组合：down-after-milliseconds 10000 + parallel-syncs 1，确保故障判断稳、切换动作轻、同步过程可控。
客户端没刷新拓扑是脑裂的最后一环
即使哨兵正确选出唯一新主，如果客户端仍缓存着旧主地址并持续写入，等同于人为制造双主。Redisson 等智能客户端默认每10秒调用 SENTINEL get-master-addr-by-name 刷新地址，但很多自研客户端直接硬编码 host:port 或依赖过期 DNS 缓存。
容易被忽略的地方：
- 客户端连接池未设置自动重连逻辑，旧连接在故障后仍维持对原主的 TCP 连接
- 应用层未监听哨兵 Pub/Sub 的
__sentinel__:hello或+switch-master事件做主动感知 - failover-timeout（默认180000ms）超时后，部分哨兵可能放弃当前流程但未通知客户端，导致状态滞留
真正决定脑裂是否落地的，往往不是哨兵选得对不对，而是客户端有没有在毫秒级内切断旧连接、建立新连接。
