不是必须跨机房部署，但不跨机房等于无容灾；主节点与其直属从节点绝不能同属一个可用区，需通过运维打标、DNS域名映射、部署脚本校验IP归属等手段强制约束。
Redis集群主从节点必须跨机房部署吗？
不是“必须”，但不跨机房就等于没做容灾。当整个机房断电或网络隔离时，如果主从都在同一个机房，redis-cli --cluster check 看起来健康，实际已完全不可用。
关键判断依据是：主节点和它直属的从节点（即 replica-of 指向它的那个）**绝不能共享同一可用区标签**。Redis 本身不识别“机房”概念，靠运维层打标 + 集群配置策略来约束。
- 真实场景中，用
redis.conf的cluster-announce-ip配合 DNS 或服务发现，把节点 IP 映射到带区域信息的域名（如redis-usw2a-01.example.com） - 部署脚本里检查
CLUSTER NODES输出，过滤出master行，再对每个 master 的slave节点查其 IP 归属——若同属usw2-a子网，立刻拒绝加入集群 - 别依赖
cluster-require-full-coverage no来掩盖问题；它只影响读写拒绝逻辑，不解决脑裂风险
如何让Redis集群自动避开同机房选主？
Redis 原生不支持基于机房的故障转移权重。所谓“自动”，其实是通过 cluster-node-timeout 和人工干预组合实现的妥协方案。
真正起作用的是：在发生主节点宕机后，由运维系统（非 Redis 自身）扫描剩余从节点的机房标签，优先向跨机房的从节点发 CLUSTER FAILOVER TAKEOVER 指令。
-
cluster-slave-validity-factor设为0可跳过复制延迟校验，但会增加数据丢失风险；生产环境建议保留默认值10，靠缩短cluster-node-timeout（如设为5000）加速感知 - 从节点所在机器需预装轻量级探测脚本，定时上报自身所在机房 ID 到 Consul/Etcd；failover 触发器读这个值做决策
- 避免使用
redis-cli --cluster rebalance自动均衡——它只看 slot 数量，完全无视物理位置
跨机房部署后延迟飙升、超时频发怎么办？
跨机房带来的 RT 增加是刚性事实，不是配置能抹平的。重点不是“压低延迟”，而是让业务接受并适配这种延迟特征。
典型表现是客户端报 READONLY You can't write against a read only replica 或 Connection refused，本质是客户端缓存了过期的拓扑，连到了刚升主但尚未完成 slot 迁移的节点。
- 客户端必须开启
refreshPeriod（Lettuce）或refreshTriggersReconnect（Jedis），间隔建议 ≤cluster-node-timeout / 2 - 禁止在应用层做“写主读从”的路由逻辑；集群模式下所有请求都应走
MOVED/ASK重定向，否则跨机房时极易路由错位 - 监控项要加一层：对每个
CLUSTER SLOTS返回结果，检查每个 slot 的主节点 IP 是否与该 slot 最近一次成功写入的节点一致；不一致即说明迁移卡住
哨兵模式能替代集群模式做跨机房容灾吗？
能，但代价是放弃数据分片能力。如果你的总量始终在单实例可承受范围内（比如 ≤ 16GB 内存、QPS ≤ 5 万），哨兵反而是更稳的选择。
哨兵的 quorum 和 down-after-milliseconds 参数在跨机房场景下比集群的 cluster-node-timeout 更可控，因为故障判定基于多数派投票而非心跳超时。
- 哨兵配置里必须显式设置
sentinel monitor <master-name> <ip> <port> <quorum>中的<ip>为跨机房可达地址（比如 VIP 或 Anycast IP），不能写本地内网地址 - 每个哨兵进程应部署在不同机房，且
sentinel known-replica列表要人工维护，确保至少一个 replica 在远端机房 - 切勿混用：同一组 Redis 实例既接入哨兵又启用
cluster-enabled yes，会导致ERR This instance has cluster support disabled类错误反复出现
跨机房的本质不是技术拼图，而是把“哪个节点挂了会影响哪些用户”这件事提前想清楚。配置写错可以改，但流量切过去才发现主从全在一个机房，那就只能等变更窗口了。
