JedisCluster在2.7.x可用，升级至2.9.x后遇连接拒绝与JedisConnectionException

我之前在跨版本升级Jedis时也踩过类似的坑，结合你从2.7.x升级到2.9.x的场景，大概率是以下几个兼容性问题导致的，给你逐一分析并给出解决方案：

1. 连接池配置的隐性变更 #

Jedis 2.9.x对JedisCluster的连接池配置逻辑做了调整，2.7.x中部分默认参数在2.9.x里被修改，而且要求显式指定连接池配置。如果你的单例初始化代码沿用了2.7.x的写法，可能会因为连接池参数不合理导致无法获取有效连接。

建议你检查JedisCluster的初始化代码，确保传入了正确的GenericObjectPoolConfig实例，并且配置了合理的连接参数：

// 初始化连接池配置
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
poolConfig.setMaxTotal(100); // 根据业务流量调整最大连接数
poolConfig.setMaxIdle(20);   // 保留的空闲连接数
poolConfig.setTestOnBorrow(true); // 借连接时验证可用性，避免拿到无效连接

// 集群节点集合
Set<HostAndPort> clusterNodes = new HashSet<>();
clusterNodes.add(new HostAndPort("redis-node-1", 6379));
clusterNodes.add(new HostAndPort("redis-node-2", 6379));
// 添加所有集群节点...

// 初始化JedisCluster，注意构造函数参数的完整性
JedisCluster jedisCluster = new JedisCluster(
    clusterNodes,
    5000, // 连接超时时间
    5000, // 读写超时时间
    3,    // 重试次数
    poolConfig
);

2. 集群拓扑刷新机制的差异 #

Jedis 2.9.x优化了集群节点拓扑的刷新逻辑，相比2.7.x更严格。如果你的Redis集群在重启后节点信息有变化，旧版本的拓扑缓存可能无法自动更新，导致JedisCluster无法连接到有效节点。

你可以在初始化JedisCluster后手动触发一次拓扑刷新，或者在构造时配置自动刷新相关参数：

// 初始化后手动刷新拓扑视图
jedisCluster.refreshClusterView();

// 或者在构造时指定超时与重试参数，帮助自动刷新拓扑
JedisCluster jedisCluster = new JedisCluster(
    clusterNodes,
    5000,
    5000,
    3, // 重试次数，帮助在节点变更时重新发现拓扑
    poolConfig
);

3. 密码认证的参数传递变化 #

如果你的Redis集群设置了密码认证，Jedis 2.9.x要求在JedisCluster构造函数中直接传入密码参数，而2.7.x可能允许通过连接池配置间接设置。如果你的代码没有适配这个变化，会因为认证失败无法连接。

修正后的带密码初始化代码：

JedisCluster jedisCluster = new JedisCluster(
    clusterNodes,
    5000,
    5000,
    3,
    "your-redis-password", // 直接传入集群密码
    poolConfig
);

排查步骤建议 #

如果以上调整都没有解决问题，建议按以下步骤定位：

• 查看日志：开启Jedis的DEBUG日志，会输出连接失败的具体原因（比如超时、认证错误、节点不可达等），这是最快速定位问题的方式。
• 验证集群可用性：用Jedis 2.9.x的命令行工具连接集群（jedis-cli -c -h 节点IP -p 端口 -a 密码），确认Redis集群本身能正常提供服务。
• 最小化测试：写一个极简的测试类，只初始化JedisCluster并调用get()方法，排查是不是业务代码中的其他逻辑（比如连接泄漏、自定义拦截器）影响了连接。

内容的提问来源于stack exchange，提问作者Kola