多机房Redis哨兵跨机房选主失败主因是slave-priority与quorum未按机房拓扑配置；需奇数哨兵、每机房至少1个、主从不同机房，slave-priority越小越优先升主，quorum应设为容忍失联哨兵数，客户端须支持动态发现并调优超时。
多机房 Redis 哨兵能自动跨机房选主，但默认配置下极大概率会脑裂或降级失败——关键不在哨兵数量，而在从库的 slave-priority 和哨兵的 quorum 配置是否与机房拓扑对齐。
为什么两个机房各放一个哨兵 + 一主一从会失败
哨兵选举依赖「多数派共识」，3 个哨兵是最低安全线。如果机房 A 放 2 个哨兵、机房 B 放 1 个，当机房 A 断网时，B 中的哨兵无法凑够 quorum（比如设为 2），无法触发故障转移；反之，若 A 中主库宕机但网络未断，B 的哨兵可能误判并试图选主，而 A 内部仍可通信，导致双主。真实场景中，这不是理论风险，而是必然发生的脑裂。
必须满足：
- 哨兵总数为奇数（推荐 3 或 5）
- 每个机房至少部署 1 个哨兵，且任意单机房故障后，剩余哨兵数 ≥ quorum
- 主库和从库不能同机房「绑定」，否则机房级故障直接全挂
如何用 slave-priority 控制跨机房升主顺序
哨兵选主时按以下优先级排序：从库优先级（slave-priority）→ 复制偏移量 → 运行 ID 字典序。机房级容灾的核心就是用 slave-priority 强制指定「备选梯队」。
例如：机房 A（主库所在）的从库设为 slave-priority 100，机房 B 的从库设为 slave-priority 10，机房 C 的从库设为 slave-priority 5。这样即使机房 A 整体失联，哨兵也会优先选 C 而非 B —— 因为数值越小优先级越高。
注意：
- slave-priority 0 表示永不参与选主，适合只做备份的冷备从库
- 修改后需执行 CONFIG REWRITE 或重启从库生效
- 该值不随主从切换自动继承，新主库升任后需手动重设（或通过配置中心统一管理）
sentinel monitor 的 quorum 参数怎么设才防脑裂
quorum 不是「总哨兵数的一半向上取整」，而是你愿意容忍多少个哨兵失联仍能安全决策的阈值。设太高，机房断网后无法转移；设太低，单个哨兵误判就可能引发错误切换。
实操建议：
- 3 个哨兵：设 quorum 2（允许 1 个失联）
- 5 个哨兵：设 quorum 3（允许 2 个失联，但需确保任意两个机房合计不少于 3 个哨兵）
- 若哨兵跨 3 机房部署（如 2+2+1），quorum 必须 ≤ 最小两机房哨兵数之和（此处为 3），否则最弱机房组合无法达成共识
修改后必须逐个重启哨兵，或用 SENTINEL SET mastername quorum 3 动态更新（需所有哨兵支持同一协议版本）。
客户端连接哨兵时最容易忽略的网络细节
客户端不是直连哨兵，而是先连哨兵查主地址，再连主库。一旦发生跨机房切换，新主库在另一机房，但客户端本地 DNS 缓存、连接池配置、超时时间往往没适配，导致大量 Connection refused 或 TimeoutException。
必须检查：
- 客户端是否启用 sentinel.getMasterAddressByName()（Jedis）或 get_primary_endpoint()（redis-py）等动态发现逻辑，而非硬编码 IP
- 连接池最大空闲连接数是否足够应对切换瞬间的连接重建洪峰
- down-after-milliseconds 在哨兵端设为 30000，但客户端读超时若只设 500ms，会在哨兵还没确认下线时就报错
真实踩坑点：某次机房 B 网络抖动 28 秒，哨兵未标记 odown，但客户端因超时频繁重试，把机房 A 的主库打满连接，反而加速了服务雪崩。
