哨兵必须跨机房部署且总数为奇数，因为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 缓存、连接池里的旧地址缓存——它们会掩盖切换事实，让问题延迟暴露
跨机房容灾最难的不是配哨兵，而是让所有客户端真正理解“主库地址是动态的”这件事。一旦漏掉这个环节，前面所有配置都白搭。
