Redis哨兵模式多机房高可用部署方案

哨兵跨机房部署且总数为奇数，这背后其实是多数派投票机制在发挥作用。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 缓存、连接池里的旧地址缓存——它们会掩盖切换事实，让问题延迟暴露

话说回来，跨机房容灾最难的不是配置哨兵，而是让所有客户端真正理解“主库地址是动态的”这件事。一旦漏掉这个环节，前面所有配置都白费。