Redis集群连接频繁报错的根本原因是节点广播的IP为127.0.0.1，导致客户端重定向失败；须配置cluster-announce-ip为真实对外IP、显式设置announce端口、执行redis-cli cluster reset hard后重启，并调优Lettuce拓扑刷新与超时参数。
redis-cli cluster nodes 返回 127.0.0.1 就别查日志了
这是最常被跳过的根因：客户端拿到的节点地址本身就是错的，后续所有超时都只是表象。执行 redis-cli -c -h 192.168.1.100 -p 6379 cluster nodes，如果输出里任意一行的 IP 是 127.0.0.1 或 0.0.0.0，那你的应用必然在重定向时连本地，然后卡死超时。
必须立刻检查每个节点的 redis.conf：
-
cluster-announce-ip必须设为该机器真实对外 IP（不能是内网 NAT 地址，也不能是容器 host 网络下的虚拟 IP） -
cluster-announce-port和cluster-announce-bus-port必须显式设置，且与实际监听端口一致 - 改完后不能只
CONFIG REWRITE或redis-cli CONFIG RELOAD—— 必须执行redis-cli cluster reset hard再重启进程，否则旧拓扑仍广播错误地址
Lettuce 客户端没开拓扑刷新，超时就是等死
Spring Boot 2.x+ 默认用 Lettuce，但它默认不自动刷新集群拓扑。主从切换后，客户端还在往旧 master 地址发请求，TCP 连接阶段就卡住，直到 spring.redis.timeout 触发 —— 这不是命令慢，是根本连不上。
检查你的配置是否包含以下关键项：
- 确认使用的是集群模式：
spring.redis.cluster.nodes已配置，且没同时配spring.redis.host - 启用主动拓扑刷新：
spring.redis.lettuce.cluster.refresh.period=30000（单位毫秒，建议 15–60 秒） - 开启自适应刷新：
spring.redis.lettuce.cluster.refresh.adaptive=true（遇到 MOVED/ASK 自动触发刷新） - 禁用错误降级：
spring.redis.lettuce.cluster.refresh.trigger.throttled=false（避免高频失败时限流）
cluster-node-timeout 和 client timeout 必须匹配
集群内部故障检测周期（cluster-node-timeout）和客户端超时（spring.redis.timeout）不协调，会放大超时现象。比如 cluster-node-timeout 设为 15000ms，但客户端只等 2000ms，结果节点刚被标记 PFAIL，客户端已经报错退出。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
生产建议值：
-
cluster-node-timeout：内网设 5000，跨可用区设 8000，全集群统一且持久化（CONFIG SET仅临时生效） -
spring.redis.timeout：至少设为cluster-node-timeout × 1.5，内网建议 3000，跨云建议 5000–8000 -
spring.redis.lettuce.pool.max-wait必须 ≥spring.redis.timeout，否则连接池等待也超时
CLUSTERDOWN 不处理，等于给线程池埋雷
CLUSTERDOWN 不是临时抖动，是集群已不可用的明确信号。很多代码 catch 到异常后静默重试或直接返回，导致线程持续阻塞在无效连接上，连接池迅速耗尽。
真正要做的只有两件事：
- 让 Lettuce 主动刷新拓扑：确保
ClusterTopologyRefreshOptions启用dynamicRefreshSources(true)和refreshTriggersOnFailure(true) - 业务层捕获
RedisCommandExecutionException，检查 message 是否含CLUSTERDOWN或MOVED，记录日志并触发一次手动刷新（connectionFactory.getClusterConnection().close()+ 新建连接） - 不要依赖 DNS 或 VIP 做故障转移 —— Redis Cluster 的 slot 路由依赖精确 IP:port，任何中间层转发都会破坏重定向逻辑
最容易被忽略的是：集群拓扑刷新不是“一劳永逸”，它依赖 gossip 协议传播，而 gossip 本身受 cluster-node-timeout 控制。调得太小会误判，太大则收敛慢 —— 没有银弹，只有根据 RTT 反复验证。
