AWS ElastiCache Redis连接池异常：持续新建连接排查求助

问题背景 #

我们的服务基于AWS ElastiCache Redis集群做数据缓存，采用Jedis客户端连接，连接池配置如下：

cachePool:
  max_total: 200
  max_idle: 200
  min_idle: 50
  block_when_exhausted: true
  max_wait_ms: 200

生产环境部署50个Pod，每个Pod对应一个Jedis客户端实例。AWS控制台显示Current Connections约2500（与50个Pod×50个空闲连接的计算值匹配），但New Connections曲线与Current Connections几乎完全重合——即使在正常流量下，服务仍持续新建约2500个连接。

排查建议 #

• 检查连接有效性验证配置
  默认Jedis未开启空闲连接有效性检查时，若AWS Redis主动断开空闲连接（如触发timeout配置或AWS连接回收机制），客户端连接池仍标记这些连接为可用，导致每次获取连接时发现无效就丢弃重建。建议：

  • 开启testWhileIdle参数，配合timeBetweenEvictionRunsMillis（如30秒）、numTestsPerEvictionRun，让连接池定期清理无效连接
  • 若对性能影响可接受，同时开启testOnBorrow，确保获取的连接一定可用

• 确认Redis服务端的连接超时配置
  登录AWS ElastiCache控制台查看Redis集群的timeout参数（单位秒），若该值远小于连接池空闲连接的存活时长，Redis会主动断开空闲连接，客户端则持续重建。建议将timeout设置为大于连接池空闲连接的预期存活时长，或与客户端空闲检查周期匹配。

• 排查Jedis客户端连接泄漏
  检查代码中是否存在连接未正确归还的情况：

  • 确保所有Jedis实例都通过try-with-resources块使用，或在finally块中调用close()归还连接
  • 排查异常分支（如捕获异常后未处理连接归还），确认无连接未释放场景
  • 可通过添加连接获取/归还日志，或用JProfiler、VisualVM等工具查看连接池的活跃/空闲连接数，对比Redis端连接数，定位是否有连接泄漏

• 检查连接池初始化与销毁逻辑

  • 确认每个Pod中JedisPool仅初始化一次，排查是否存在请求线程中重复创建连接池的逻辑（会导致每个请求新建连接池，进而产生大量连接）
  • 检查Pod生命周期，是否存在频繁重启（如健康检查失败）的情况——每次重启都会初始化连接池并创建min_idle个连接，导致New Connections持续上升

• 验证集群模式下的连接处理逻辑
  若使用Redis集群，需确认是否正确使用JedisCluster而非多个独立JedisPool：

  • 误用多个JedisPool连接集群节点会导致连接数翻倍（每个节点有独立连接池），AWS控制台的Current Connections是所有节点的连接总和，需确认客户端集群连接逻辑正确
  • 检查JedisCluster的连接池配置是否正确应用到每个节点，避免因单个节点连接失效导致全集群重建连接

• 查看连接日志定位根因

  • 在Jedis客户端开启DEBUG级别日志，查看连接创建、销毁、验证的详细记录，确认是否有频繁的连接销毁重建操作
  • 查看AWS ElastiCache的日志，确认连接断开的原因（如idle connection timeout、client closed connection），定位连接断开的触发源

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