quorum设为1时网络分区必然触发双主；因任意哨兵可单独判定主观下线并发起故障转移，分区后两边各自选举新主，导致数据分裂与丢失。
因为哨兵的投票机制在分区后仍能各自达成“多数共识”，而 Redis 主节点又不会主动退出写状态——网络一断，两个“合法主”就自然诞生了。
quorum 配置让每个分区都能独立触发故障转移
哨兵判断主节点下线需要满足 quorum（仲裁数），这个值默认是哨兵总数的一半向上取整。比如 3 个哨兵，quorum=2；但一旦网络分区把哨兵拆成 2+1，2 个哨兵所在的分区只要能互相通信、又连不上主节点，就立刻满足 quorum 条件，直接走完客观下线 → 选举新主流程。
此时另一个分区里那个“被隔离但活着”的主节点，完全不知道自己已被放弃，继续响应客户端写请求——双主已成事实。
常见错误现象：
- 监控看到两个节点都返回
role:master - 客户端日志里交替出现
READONLY You can't write against a read only replica和正常写入 - 哨兵日志中同时存在
+sdown和+odown记录，但发生在不同时间戳段
min-slaves-to-write=0 或过小会放大脑裂危害
这个配置控制主节点是否允许写入，但它只检查“本地连接的从节点数量”，不验证这些从节点是否还能跟哨兵或其他节点通信。当网络分区发生时：
- 如果设为
min-slaves-to-write 0，旧主节点毫无约束，照常写入 - 如果设为
min-slaves-to-write 1，只要它还能连上一个同分区的从节点（哪怕该从节点也已失联于多数派），就认为满足条件
结果就是：脑裂不仅发生，还带上了“合法写权限”。等网络恢复，旧主降级同步时，它在分区期间写的全部数据都会被清空——不是宕机丢数据，是被自己“合规地”删掉的。
down-after-milliseconds 设置太短会误判“假死”
这个参数定义哨兵多久没收到主节点心跳就标记为主观下线。生产环境若设成 down-after-milliseconds 3000，而跨机房链路平均 RTT 是 2800ms、偶尔抖动到 3500ms，就会频繁触发误判。
尤其在高负载场景下：
- CPU 满载导致 Redis 无法及时处理
PING回复 - 大 key 删除或
KEYS *类慢查询阻塞主线程，心跳延迟突增 - 哨兵本身部署在同一台宿主机上，受相同资源瓶颈影响
这些都不是真故障，但足够让哨兵集群在几秒内完成一次完整故障转移——而原主节点可能 2 秒后就恢复响应，此时双主已并存。
哨兵节点数为偶数时投票更容易分裂
3 个哨兵，quorum=2，分区成 2+1，只有 2 那边能投票；但如果是 4 个哨兵，quorum=3，一旦分区成 2+2，两边都达不到 quorum，看似安全——可现实更危险：任意一边只要再挂掉 1 个，剩下那个分区的 2 个哨兵就刚好卡在 quorum-1 边缘，稍有延迟波动就集体翻车。
真正稳定的最小部署是 3 个哨兵（奇数），且必须跨物理区域部署：比如 A 机房 2 个、B 机房 1 个，避免单点网络中断直接干掉多数派。
最容易被忽略的一点：哨兵的 quorum 是按“存活且能互相通信的哨兵数”动态计算的，不是静态配置值。你改了配置文件却没重启哨兵进程，或者某哨兵因 OOM 被系统 kill 后未自动拉起，实际运行中的 quorum 可能早已失效。
