Redis 7.0 集群不识别可用区（AZ），跨AZ容灾需人工校验与打标，主从必须分属不同AZ，部署前须拦截同AZ主从组合，故障转移依赖外部脚本按AZ标签触发CLUSTER FAILOVER TAKEOVER。
Redis 7.0 集群本身不识别可用区（AZ），所谓“跨 AZ 容灾”完全依赖外部约束；不做人工校验和打标，redis-cli --cluster create 创建出来的集群大概率主从同 AZ，机房故障时直接全挂。
主从节点必须分属不同可用区，但 Redis 不自动感知 AZ
Redis 的 CLUSTER NODES 输出只有 IP 和端口，没有 az、region 等字段。它不会拒绝同 AZ 的主从配对，也不会在故障转移时优先选跨 AZ 节点。
- 常见错误现象：
redis-cli --cluster create 10.10.1.5:7000 10.10.2.8:7000 ...看似跨子网，但两个 IP 实际都落在usw2-a机房内，部署脚本没查元数据就放行 - 运维层必须补足 AZ 信息：启动前写入
/etc/redis/az-id，或用 DNS 域名映射（如redis-usw2a-01.example.com→ 实际 IP），让cluster-announce-ip设为该域名 - 禁止依赖
cluster-require-full-coverage no掩盖问题——它只让客户端继续读，但无法防止脑裂或写入丢失
部署脚本必须在 add-node 前校验 AZ 归属
不能等 redis-cli --cluster create 执行完再检查；必须在节点加入集群前，就拦截同 AZ 的主从组合。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对每个 master，执行
CLUSTER NODES | grep -v master | awk '{print $3}' | cut -d@ -f1提取其 slave 的 IP - 对每个 slave IP，调用内部探测接口（如
curl -s http://metadata/az或查 Consul）确认 AZ 标签 - 任一 slave 与 master 的 AZ 标签相同，立即中止部署并报错
- 别用
redis-cli --cluster rebalance自动调整——它只看 slot 数量，完全无视物理位置
故障转移必须由外部系统触发跨 AZ 选主
Redis Cluster 不支持 failover-priority-by-az 这类配置。所谓“自动跨 AZ 切换”，本质是巡检脚本+人工干预的组合动作。
- 当
cluster-node-timeout触发主节点下线后，Redis 自身只会随机选一个在线 slave 执行CLUSTER FAILOVER - 真实容灾流程：外部脚本扫描所有 slave 的 AZ 标签，仅向跨 AZ 的 slave 发送
CLUSTER FAILOVER TAKEOVER -
cluster-slave-validity-factor建议保留默认值10，避免因复制延迟丢数据；若要加速感知故障，应缩短cluster-node-timeout（如设为5000），而非关掉校验 - 从节点机器需预装轻量探测脚本，定时上报自身 AZ ID 到 Consul/Etcd；failover 触发器必须读这个值决策，不能依赖节点本地文件
客户端必须适配跨 AZ 带来的延迟特征
跨 AZ 的 RT 增加是刚性事实，不是靠调参能抹平的。业务层不配合，再好的拓扑也白搭。
- 典型错误表现：客户端缓存了过期拓扑，连到刚升主但尚未完成 slot 迁移的节点，报
READONLY You can't write against a read only replica或Connection refused - 客户端必须开启拓扑刷新机制：Lettuce 配
refreshPeriod，Jedis 配refreshTriggersReconnect，间隔建议 ≤cluster-node-timeout / 2 - 禁止在应用层做“写主读从”的路由逻辑；集群模式下所有请求都应走
MOVED/ASK重定向，由客户端 SDK 自动处理
最易被忽略的一点：所有节点的 cluster-config-file 必须可写，否则 Redis 启动后无法持久化 AZ 相关的动态拓扑变更，后续任何校验和 failover 都会失效。
