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缓存、连接池里的旧地址缓存——它们会掩盖切换事实，让问题延迟暴露

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