redis哨兵跨机房故障转移关键在于切得对、稳、不丢数据，需哨兵跨机房部署≥3个、合理设quorum、从库slave-priority控制选主、min-replicas-to-write防脑裂、客户端自动监听+switch-master刷新地址。

Redis 哨兵集群实现跨机房故障转移，关键不在“能不能切”，而在“切得对、切得稳、不丢数据”。它不是靠哨兵“主动指定”新主，而是靠合理分布 + 明确规则 + 写保护共同保障。

哨兵必须跨机房部署，且数量≥3

所有哨兵不能放在同一个机房。因为 ODOWN（客观下线）判定依赖多数派投票：如果 3 个哨兵全在机房 A，A 断网后，哪怕机房 B 的 Redis 实例全部正常，哨兵之间也失联，无法达成共识，故障转移直接卡死，SENTINEL ckquorum mymaster 返回 NOQUORUM 就是典型表现。

• 最低要求：至少 3 个哨兵，分属至少两个机房（例如机房 A 放 2 个，机房 B 放 1 个）
• 更稳妥方案：机房 A 和 B 各放 2 个（共 4 个），避免单机房故障导致仲裁失效
• quorum 值要匹配部署：3 个哨兵设为 2，4 个哨兵建议设为 3（奇数更防平票）

从库优先级决定谁当新主

哨兵不“指定”新主，只按固定规则打分排序：slave-priority → 复制偏移量 → runid 字典序。所以控制权在从库配置里，不在选举瞬间。

Redis Skill - 高性能缓存管理

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

下载

• 把目标机房（如机房 B）的从库 slave-priority 设为 10（默认 100，值越小越优先）
• 把原主库所在机房（机房 A）的从库 slave-priority 设为 100 或更高，强制降级其候选资格
• 确保目标从库开启 replica-serve-stale-data no，防止网络抖动时提供过期数据干扰判断

用写保护防脑裂丢数据

跨机房异步复制 + 网络分区 = 脑裂高发。典型场景：机房 A 断网，哨兵在 A 内选新主；机房 B 的旧主仍在写；恢复后双主并存，新写入被覆盖。

• 在主库配置 min-replicas-to-write 1 和 min-replicas-max-lag 300（单位毫秒）
• 含义：至少有 1 个从库延迟 ≤300ms，才允许写；否则拒绝写命令，返回 BUSYLOAD 错误
• 300 这个值应基于实测 P99 延迟的 2–3 倍设定（例如链路 P99 是 120ms，就设 300–400ms）

客户端需支持自动重连与配置刷新

故障转移完成后，哨兵通过 PUB/SUB 频道（如 +switch-master）通知变更。客户端必须能监听并更新主节点地址，否则仍连旧主失败。

• Java 客户端（如 Jedis、Lettuce）需启用 sentinel 自动发现，并设置合理的 refreshPeriod（如 1–5 秒）
• Python 客户端（redis-py）使用 Sentinel 类连接，内部会自动订阅并更新
• 避免硬编码主库地址，一律通过哨兵获取 master 地址：sentinel.discover_master("mymaster")