spring.redis.cluster.nodes仅配置节点列表，无法实现跨机房容灾；真正容灾需多集群+运行时切换逻辑+应用层熔断与拓扑重置，且A/B机房数据天然异步、slot映射不一致。
spring.redis.cluster.nodes 配置本身不支持跨机房容灾，它只是告诉客户端“有哪些节点可连”，但无法自动感知机房故障、切换集群或路由请求。真要实现跨机房容灾，必须靠多集群 + 显式切换逻辑 + 代理层协同，不是改几个 yml 就能生效的。
跨机房场景下 cluster.nodes 失效的本质原因
Redis Cluster 协议要求客户端自行解析拓扑、计算 slot、重定向请求。当客户端通过 cluster.nodes 连上 A 机房集群后，它会缓存该集群的 slot 分配表（比如 slot 0–5460 → 10.10.1.1:7001）。如果 A 机房整体断网，Lettuce 默认只会尝试重连这些地址，不会主动查 B 机房的集群——因为它根本不知道 B 机房的存在。
- 报错典型表现：
Unable to connect to [10.10.1.1:7001]: connection timed out持续刷屏，但日志里完全不提备用集群 - 即使你把 B 机房节点也写进
nodes列表（如10.10.1.1:7001,10.20.1.1:7001），Lettuce 仍会按顺序尝试所有地址，最终因跨机房延迟高、连接超时多而卡死或降级失败 - Redis Cluster 不支持“双写”或“主从跨集群同步”，A/B 机房数据天然异步，切换必丢数据——这点必须由业务层兜底
必须手动维护多套 RedisConnectionFactory
Spring Boot 的自动配置只支持单套 RedisConnectionFactory，跨机房容灾需放弃 spring.redis.cluster.* 全自动方式，改为手写多实例：
- 定义两个独立的
@Configuration类，分别对应primaryClusterFactory和backupClusterFactory，各自用RedisClusterConfiguration构造，且setPassword()、setTimeout()等参数单独设（B 机房网络延迟通常更高，timeout建议设为5000） - 用
@Primary标记主集群工厂，避免注入冲突；备份工厂加@Qualifier("backupRedisConnectionFactory") - 不要复用同一个
GenericObjectPoolConfig实例——连接池参数（如max-idle）应按机房实际负载调优，B 机房连接数上限通常更低 - 示例关键代码：
@Bean(name = "backupRedisConnectionFactory") public RedisConnectionFactory backupRedisConnectionFactory() { RedisClusterConfiguration config = new RedisClusterConfiguration( Arrays.asList("10.20.1.1:7001", "10.20.1.2:7001")); config.setPassword("xxx"); LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder() .commandTimeout(Duration.ofMillis(5000)) .build(); return new LettuceConnectionFactory(config, clientConfig); }
切换逻辑不能依赖 @ConditionalOnProperty
靠改配置文件开关机房是危险的：应用重启前旧连接还在用，重启中可能双写冲突，且无法做灰度验证。真实可用的切换必须是运行时可控的：
- 用
AtomicReference<RedisConnectionFactory>包裹当前活跃工厂，提供switchToBackup()和switchToPrimary()方法 - 切换时需清空本地 slot 缓存（Lettuce 的
ClusterTopologyRefreshOptions不保证立即刷新，得调redisConnectionFactory.reset()） - 务必加熔断保护：连续 3 次
backup请求超时，自动回切，并发请求量突增时拒绝新请求（用Resilience4j或简单计数器） - 关键点：切换后首次
MGET或pipeline很可能失败——因为新工厂尚未完成 topology fetch，需加重试（最多 2 次）和 fallback 日志
代理层（如 Twemproxy / Redis-Proxy）只能缓解，不能替代应用层控制
在机房入口部署代理，把 redis://vip:6379 流量转发到当前健康集群，看似优雅，但有硬伤：
- 代理无法识别 Redis Cluster 的
MOVED/ASK重定向响应，遇到跨 slot 批量操作（如MGET k1 k2 k3）直接报错，而应用层自己构造的LettuceConnectionFactory能正确处理重定向 - 代理层无业务语义，无法做读写分离（如写必须打主集群，读可降级到备集群）、无法按 key 分类路由（用户态数据走 A，日志态走 B）
- 代理自身成单点：它的健康检查若只 ping TCP 端口，可能漏掉集群内部脑裂；真要高可用，得再套一层 VIP + Keepalived，复杂度陡增
- 真正省事的做法是：代理仅作 DNS 层流量入口（如
redis-primary.example.com→ A 机房 VIP，redis-backup.example.com→ B 机房 VIP），切换靠 DNS TTL 缩短+应用层RedisConnectionFactory动态重建
KEYS pattern 或 SCAN 在备集群查不到数据。这不是配置问题，是架构前提——必须接受“跨机房不保证数据强一致”，所有依赖全量扫描的逻辑，得提前改造成按业务维度分片查询。 
