不是必须跨机房部署但不跨机房等于无容灾主节点与其直属从节点绝不能同属一个可用区需通过运维打标、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/Etcdfailover 触发器读这个值做决策避免使用 redis-cli --cluster rebalance 自动均衡——它只看 slot 数量完全无视物理位置跨机房部署后延迟飙升、超时频发怎么办跨机房带来的 RT 增加是刚性事实不是配置能抹平的。重点不是“压低延迟”而是让业务接受并适配这种延迟特征。 云从科技AI开放平台 云从AI开放平台