哨兵跨机房部署且总数为奇数，这背后其实是多数派投票机制在发挥作用。ODOWN 判定依赖的是多数派投票，而不是单个哨兵在线就能正常运作。如果所有哨兵都集中在同一个机房，一旦该机房断网，即使其他机房的 Redis 主从实例均运行正常，哨兵也会集体失联，此时 SENTINEL ckquorum mymaster 会直接返回 NOQUORUM，导致故障转移无法启动。
为什么哨兵必须跨机房部署且总数为奇数
原因很简单：ODOWN 判定依赖多数派投票，并非“只要有 1 个哨兵在线就能执行”。如果所有哨兵都在机房 A，A 断网后，即便机房 B 的主从都正常，哨兵也会集体失联，SENTINEL ckquorum mymaster 会返回 NOQUORUM，故障转移直接被卡死。实际部署需满足三个条件：
- 哨兵总数为奇数（推荐 3 或 5），避免平票情况
- 每个机房至少部署 1 个哨兵，且任意单机房故障后，剩余哨兵数 ≥ quorum
- 不能将哨兵和 Redis 实例混部在同一台机器——资源争抢可能触发
down-after-milliseconds误判
sentinel monitor 的 quorum 参数怎么设才不脑裂
quorum 参数，很多人的第一反应是“总哨兵数除以 2 向上取整”。但实际并非如此。quorum 不是计算出来的，而是你愿意容忍多少个哨兵失联后仍能安全决策。设得太高，机房断网时无法转移；设得太低，单个哨兵误判就可能错误切换。常见组合与配置如下：
- 3 个哨兵（如 A 机房 2 个、B 机房 1 个）：设 quorum 为 2（允许 1 个失联）
- 5 个哨兵（如 A/B/C 机房分别 2/2/1）：设 quorum 为 3，但需确保任意两个机房的哨兵数之和 ≥ 3（否则弱组合无法达成共识）
- 修改后需逐个执行
SENTINEL SET mymaster quorum 3，或重启哨兵（要求所有哨兵协议版本一致）
如何用 slave-priority 控制跨机房升主顺序
哨兵选主这件事，其实不像很多人想象的那样可以“指定”选谁。它只看三件事：从库 slave-priority → 复制偏移量 → runid 字典序。这三项指标决定了最终选主结果，全靠你提前配置好优先级。比如主库在机房 A，你想让机房 C 的从库优先升主（而非 B），就设：
- 机房 C 从库：
slave-priority 5 - 机房 B 从库：
slave-priority 10 - 机房 A 从库：
slave-priority 100（默认值，降级为最后备选） slave-priority 0表示永不参与选主，适合冷备从库- 改完要执行
CONFIG REWRITE或重启从库生效；主从切换后新主库不会自动继承该值，需手动重设或用配置中心统管
客户端连不上新主库？大概率是没走哨兵发现流程
很多团队踩过这个坑：客户端写死了旧主库的 IP 地址，等着哨兵一切换，旧主变从，新主换了 IP，请求还在往老地址发，结果直接报 READONLY You can't write against a read only replica 或连接拒绝。正确做法只有一条：客户端必须通过哨兵列表动态获取主库地址。
- Python 用 redis-py：初始化 Sentinel 实例，调用
sentinel.discover_master("mymaster") - Java 用 JedisSentinelPool：传入哨兵地址集合，不要硬编码主库 IP
- 禁用 DNS 缓存、连接池里的旧地址缓存——它们会掩盖切换事实，让问题延迟暴露
话说回来，跨机房容灾最难的不是配置哨兵，而是让所有客户端真正理解“主库地址是动态的”这件事。一旦漏掉这个环节，前面所有配置都白费。
