Redis原生不识别可用区，因CLUSTER NODES仅输出IP端口而无物理位置元数据；跨AZ需运维层通过DNS映射、服务发现或启动打标等方式补足AZ信息，并在节点加入前强制校验主从分属不同AZ。
主节点和它直属的从节点绝不能在同一个可用区，否则所谓“跨AZ”只是假象，机房级故障时整个分片直接不可用。
为什么 Redis 集群原生不识别“可用区”
Redis 本身没有 zone、az 或 region 这类配置项；CLUSTER NODES 输出里只有 IP 和端口，不带任何物理位置元数据。所谓“跨 AZ”，全靠运维层补足：比如在节点启动前打标（如写入 /etc/redis/az-id）、用 DNS 域名映射（redis-usw2a-01.example.com → 实际 IP），或通过服务发现系统（Consul/Etcd）维护节点与 AZ 的绑定关系。
常见错误现象：
- 部署脚本没校验 IP 段，把
10.10.1.5（usw2-a）和10.10.2.8（usw2-b）都当成“同地域”放行，实际是同一机房子网 - 用
redis-cli --cluster create直接指定所有 IP，没提前过滤掉同 AZ 的 slave，集群创建成功但拓扑违规
如何强制主从节点交叉分布在不同 AZ
关键不是“让 Redis 自动做”，而是“在加入集群前就卡住违规节点”。实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个节点启动时，通过
cluster-announce-ip设为带区域信息的域名（如redis-usw2a-01.example.com），再由 DNS 解析到真实 IP —— 这样CLUSTER NODES输出里就能看到可解析的 AZ 标识 - 写部署脚本，在执行
redis-cli --cluster add-node前，先查当前 master 的所有 slave 节点：CLUSTER NODES | grep -v master | awk '{print $3}' | cut -d@ -f1，再对每个 IP 调用内部探测接口（如curl -s http://metadata/az）确认归属，任一 slave 与 master 同 AZ 就中止 - 禁用
cluster-require-full-coverage no掩盖问题——它只让客户端继续读，但无法防止脑裂或写入丢失
故障转移时如何优先选跨 AZ 的从节点
Redis Cluster 不支持基于 AZ 的 failover 权重，所谓“自动选跨区节点”其实是运维系统干预的结果：
- 当
cluster-node-timeout触发主节点下线后，由外部巡检脚本（非 Redis 自身）扫描所有 slave 节点的 AZ 标签，只向跨 AZ 的 slave 发送CLUSTER FAILOVER TAKEOVER -
cluster-slave-validity-factor建议保留默认值10，避免因复制延迟丢数据；若真要加速选主，应缩短cluster-node-timeout（如设为5000），而非关掉校验 - 从节点机器需预装轻量探测脚本，定时上报自身 AZ ID 到 Consul；failover 触发器必须读这个值决策，不能依赖节点本地配置（可能被覆盖）
客户端连不上、报 READONLY 或 Connection refused 怎么办
这不是 Redis 配置问题，而是客户端缓存了过期拓扑：
- 新主节点刚完成
FAILOVER TAKEOVER，但 slot 迁移尚未广播完成，客户端仍按旧拓扑连到刚升主但未接管 slot 的节点，于是报READONLY You can't write against a read only replica - 客户端必须开启拓扑刷新机制：
refreshPeriod（Lettuce）或refreshTriggersReconnect（Jedis），间隔 ≤cluster-node-timeout / 2（如 timeout=5000，则刷新周期 ≤ 2500ms） - 禁止在应用层做“写主读从”的路由逻辑——集群模式下所有请求都应接受
MOVED/ASK重定向，由客户端 SDK 处理
最易被忽略的一点：跨 AZ 带来的网络延迟是刚性事实，没法靠调参抹平；真正要做的不是压低 RT，而是让客户端能感知拓扑变更、容忍短暂重试，并确保运维系统能在故障窗口内完成跨 AZ 的主从切换判定与指令下发。
