哨兵必须跨机房部署且总数为奇数，因为odown判定依赖多数派投票，单机房断网会导致哨兵集体失联、noquorum；奇数节点避免平票，确保任意单机房故障后剩余哨兵数≥quorum，从而可靠触发故障转移。

为什么哨兵必须跨机房部署且总数为奇数

因为哨兵的 ODOWN 判定依赖多数派投票，不是“只要有1个哨兵在线就能干活”。如果所有哨兵都在机房 A，A 断网后，哪怕机房 B 的主从都正常，哨兵也集体失联，SENTINEL ckquorum mymaster 会返回 NOQUORUM，故障转移卡死。

实操上必须满足：

• 哨兵总数为奇数（推荐 3 或 5），避免平票
• 每个机房至少部署 1 个哨兵，且任意单机房故障后，剩余哨兵数 ≥ quorum
• 不能把哨兵和 Redis 实例混部在同一台机器——资源争抢可能触发 down-after-milliseconds 误判

sentinel monitor 的 quorum 参数怎么设才不脑裂

quorum 不是“总哨兵数除以 2 向上取整”，而是你愿意容忍多少个哨兵失联仍能安全决策。设太高，机房断网无法转移；设太低，单个哨兵误判就可能错误切换。

常见组合与配置：

• 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 字典序。它不会“指定”选谁，全靠你提前配好优先级。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

比如主库在机房 A，你想让机房 C 的从库优先升主（而非 B），就设：

• 机房 C 从库：slave-priority 5
• 机房 B 从库：slave-priority 10
• 机房 A 从库：slave-priority 100（默认值，降级为最后备选）
• slave-priority 0 表示永不参与选主，适合冷备从库
• 改完要执行 CONFIG REWRITE 或重启从库生效；主从切换后新主库不会自动继承该值，得手动重设或用配置中心统管

客户端连不上新主库？大概率是没走哨兵发现流程

很多团队把连接写成 redis://192.168.1.10:6379，等哨兵切主后，旧主变从、新主换 IP，客户端还在往老地址发请求，直接报 READONLY You can't write against a read only replica 或连接拒绝。

正确做法只有一条：客户端必须通过哨兵列表动态获取主库地址。

• Python 用 redis-py：初始化 Sentinel 实例，调 sentinel.discover_master("mymaster")
• Java 用 JedisSentinelPool：传入哨兵地址集合，不要硬编码主库 IP
• 禁用 DNS 缓存、连接池里的旧地址缓存——它们会掩盖切换事实，让问题延迟暴露

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