JedisClusterMaxAttemptsException不是连接失败，而是重试耗尽：它表示Jedis已按策略重试默认次数（通常5次），但每次均因连接断开、密码错误、重定向循环、节点不可达或集群元数据混乱而失败，本质是重试机制兜底失败。
为什么JedisClusterMaxAttemptsException不是连接失败，而是重试耗尽
JedisClusterMaxAttemptsException: No more cluster attempts left 这个异常不表示“连不上”，而是说 Jedis 已经按策略重试了默认次数（通常是 5 次），但每次尝试都因某种原因失败了——可能是连接断开、密码错误、重定向循环、节点不可达或集群元数据混乱。它本质是「重试机制兜底失败」，不是底层网络不通的初级问题。
检查初始节点列表是否包含真实可通信的集群节点
客户端初始化 JedisCluster 时传入的 Set<HostAndPort> 是“入口点”，Jedis 会先连其中一个获取集群拓扑，再自动发现其余节点。如果这些初始节点本身不可达，或返回的拓扑里全是 127.0.0.1 / 内网 IP（而客户端在另一台机器上），后续所有重试都会打偏。
- 确保每个
HostAndPort的 IP 是客户端能直接路由到的地址，不是127.0.0.1或 Docker 容器内网地址 - 用
telnet 公网IP 端口或nc -zv 公网IP 端口实测连通性，不只是看 Redis 进程是否在跑 - 若用阿里云等托管 Redis，确认白名单已放行客户端所在机器的公网 IP 段，仅放行内网段不够
- 集群节点间也要能互相通信——特别是端口
17000-17005（即redis port + 10000）必须开放，否则集群握手失败，JedisCluster获取不到完整拓扑
验证集群状态和节点密码一致性
这个异常常由两类静默不匹配触发：一是集群中部分节点没配密码，但客户端带了 password；二是集群正在主从切换或某节点 CLUSTERDOWN，但 Jedis 仍试图向它发请求。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 登录任意节点执行
redis-cli -p 7001 -c cluster nodes，检查输出中是否有大量fail或noaddr状态节点 - 逐个检查每个节点的
redis.conf是否都启用了requirepass，且密码一致；否则遇到无密码节点时会抛ERR Client sent AUTH, but no password is set，触发重试 - 若刚重启过集群，确认没残留
.rdb或.aof文件导致节点启动后卡在加载状态（此时redis-cli -c可连，但JedisCluster会因元数据不全反复重试） - 避免在运维操作（如主从切换、节点下线）窗口期发起业务请求
抓关键日志定位是哪类失败在驱动重试
异常堆栈本身不说明根本原因，要看 JedisClusterCommand#runWithRetries 内部捕获的真实异常类型。开启 DEBUG 日志（如 Logback 中设置 logger name="redis.clients.jedis" level="DEBUG"）能暴露每次重试抛出的原始异常。
- 如果是
JedisConnectionException：说明网络或认证层失败，聚焦防火墙、IP、端口、密码 - 如果是
JedisRedirectionException（含MOVED/ASK）：说明请求被重定向，但重定向目标不可达或又跳转，形成循环——常见于集群节点返回的 IP 是它自己的内网地址，客户端无法访问 - 如果是
JedisClusterException: CLUSTERDOWN：集群尚未完成握手或某个分片完全不可用，需人工介入修复节点或等待收敛
真正难排查的，往往不是配置错在哪一行，而是集群拓扑信息在客户端、节点、网络三者之间存在“认知差”——比如节点告诉客户端“我在 172.18.0.5:7001”，但客户端根本 ping 不通这个地址。这种错位不会报明确错误，只会让 Jedis 在暗处反复撞墙。
