多机房部署不等于多机房备份，真正有效的备份需满足数据可读、拓扑可感知、切换可验证三硬条件；Redis Cluster跨机房无法自动接管slot，哨兵默认不跨机房选主，异步复制导致RPO>0，须严控网络延迟、节点规模与客户端拓扑发现机制。
很多团队把“同城双机房部署 Redis Cluster”当成容灾方案，上线后就以为雪崩风险归零。结果一次跨机房网络抖动，CLUSTER NODES 输出满屏 fail?，客户端持续打到已下线节点，role:slave 却始终不升主——这不是备份失效，是压根没配对。
真正起作用的多机房“备份”，必须满足三个硬条件：数据可读、拓扑可感知、切换可验证。
为什么单纯跨机房部署 Redis Cluster 不等于备份
Redis Cluster 的 slot 分配是静态绑定的：slot 12345 固定归属机房 A 的某个 master，机房 B 的节点即使存活，也无法接管该 slot，除非人工执行 redis-cli --cluster reshard 并重配 proxy 路由。
哨兵模式下，sentinel failover 默认只在同机房内选主；跨机房触发需显式配置 quorum 和调低 down-after-milliseconds，否则极易脑裂。
异步复制下，机房 B 的从节点可能落后数秒甚至更久，RPO > 0 是常态；若未开启 min-replicas-to-write 2，写请求可能成功返回却未同步到备机房。
能落地的多机房备份必须做这三件事
网络延迟必须稳定 ≤ 5ms（P99），否则 Gossip 协议频繁超时，集群状态反复震荡，CLUSTER INFO 中 cluster_state:fail 会周期性出现
每个机房至少部署 3 个 master（共 ≥6 个），且必须设 cluster-require-full-coverage no，否则任一机房失联即整个集群拒绝服务
客户端 SDK 必须启用拓扑自动发现：Lettuce 6.3+ 需用 ClusterTopologyProvider，禁用 StaticMasterSlaveTopologyProvider；Spring Data Redis 3.2+ 要确认 redis.cluster.refresh.period 已生效
切换后最常被忽略的验证点
执行完 SENTINEL failover mymaster 或 CLUSTER FAILOVER 后，立刻用 redis-cli -h new-master info replication 检查是否真为 role:master，而非仍显示 role:slave
用 redis-cli --cluster check 确认无 Slot XXX has no owner 报错，否则说明原节点未彻底下线，nodes.conf 里残留旧配置
切到备机房后抽样验证 key 存在性：对热点 key 执行 GET + TTL，避免因 AOF 重写中断或 RDB 传输失败导致部分 key 缺失
真正的备份不是“多放几台机器”，而是让任一机房故障时，剩余节点能立刻承接流量、数据不丢、客户端不迷路。这三个条件缺一不可，漏掉任意一个，所谓多机房就只是多了一层幻觉。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
