跨机房高可用必须满足三条件：哨兵跨机房且总数为奇数、quorum值与部署严格匹配、客户端动态获取主地址；缺一则故障时卡noquorum或连错节点。
跨机房高可用容灾在哨兵模式下不是“配好就能用”，而是必须满足三个硬性条件：哨兵跨机房且总数为奇数、quorum值与部署结构严格匹配、客户端不硬编码地址。缺一不可，否则故障时大概率卡在 NOQUORUM 或连错节点。
哨兵节点必须跨机房且总数为奇数
所有哨兵挤在一个机房，等于把仲裁权交给单点网络——机房A断网，哪怕B和C的Redis主从全在线，哨兵之间也失联，SENTINEL ckquorum mymaster 直接返回 NOQUORUM，故障转移彻底停滞。
- 最低可行方案：3个哨兵，分属至少两个机房（如机房A放2个、机房B放1个）
- 更稳妥方案：5个哨兵，按 2+2+1 或 3+1+1 分布，确保任意单机房故障后剩余哨兵数 ≥
quorum - 绝对禁止：哨兵和它监控的Redis实例混部在同一台机器上——资源争抢可能触发
down-after-milliseconds误判
quorum 值不能简单设为哨兵数÷2向上取整
quorum 是你愿意容忍多少个哨兵失联仍能安全决策的阈值，不是数学题。设太高，机房断网无法触发转移；设太低，单个哨兵网络抖动就可能误切主。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 3个哨兵（2+1分布）→
quorum设为 2（允许1个失联） - 5个哨兵（2+2+1分布）→
quorum设为 3，但必须保证任意两个机房的哨兵数之和 ≥ 3，否则弱组合无法达成共识 - 修改后需逐个执行
SENTINEL SET mymaster quorum 3，或重启哨兵（要求所有哨兵协议版本一致）
slave-priority 决定谁当新主，不是哨兵“指定”的
哨兵选主只看三件事：slave-priority → 复制偏移量 → runid 字典序。它不会跳过规则去“指定”某台机器升主，所以控制权完全在从库配置里。
- 想让机房C的从库优先升主？设其
slave-priority 5 - 原主库所在机房A的从库，设
slave-priority 100（默认值）或更高，强制降级 -
slave-priority 0表示永不参与选主，适合冷备从库 - 改完要执行
CONFIG REWRITE或重启从库生效；主从切换后新主库不会自动继承该值，得手动重设或用配置中心统管
客户端必须监听 +switch-master，不能硬编码主库地址
很多故障不是出在哨兵，而是客户端还连着旧主。哨兵切完主后发 +switch-master 事件，如果客户端没订阅、没刷新连接，就会持续收到 READONLY 错误。
- Java 客户端（Lettuce）需启用
sentinel自动发现，并设置refreshPeriod=1000～5000毫秒 - Python 客户端（redis-py）用
Sentinel类连接，内部自动订阅并更新 - 绝对禁止写死
redis://192.168.1.10:6379这类地址，一律通过sentinel.discover_master("mymaster")动态获取
最容易被忽略的是 min-replicas-to-write 和 min-replicas-max-lag 这两个参数——它们不在哨兵配置里，而在 Redis 主节点的 redis.conf 中。不配，跨机房脑裂时旧主恢复后照常写入，新写数据直接丢失。这个保护动作，哨兵本身完全不参与，全靠主节点自己拒绝写请求。
