Redis报错:JedisConnectionException: Could not get a resource from the pool

1、问题描述:
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

2、简要分析:

redis.clients.util.Pool.getResource会从JedisPool实例池中返回一个可用的redis连接。分析源码可知JedisPool 继承了 redis.clients.util.Pool ,而这个Pool是通过commons-pool开源工具包中的org.apache.commons.pool2.impl.GenericObjectPool来实现对Jedis实例的管理的。所以我们分析一下GenericObjectPool或许能找到答案。

其中GenericObjectPool三个重要个几个属性是:

MaxActive: 最大连接数

MaxIdle: 最大空闲数

MaxWait: 最大等待时间,单位毫秒(million seconds)

连接池中无可用连接时会会进行等待maxWait时间,若超出泽抛Could not get a resource from the pool异常。所以应根据程序实际情况合理设置这三个参数的值,尽量避免这个异常。

分析结果:
如果连接池没有可用Jedis连接,会等待maxWaitMillis(毫秒),依然没有获取到可用Jedis连接,会抛出这个异常:redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

3、发生异常可能的情况

异常原因一 、客户端没有从连接池(最大maxTotal个)拿到可用Jedis连接造成的【简称连接泄露 (常见)】

分析图如下:

JedisPool默认的maxTotal=8,下面的代码从JedisPool中借了8次Jedis,但是没有归还,当第9次(jedisPool.getResource().ping())

复制代码
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisPool jedisPool = new JedisPool(poolConfig, "127.0.0.1", 6379);
//向JedisPool借用8次连接,但是没有执行归还操作。
for (int i = 0; i < 8; i++) {
    Jedis jedis = null;
    try {
        jedis = jedisPool.getResource();
        jedis.ping();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    }
}
jedisPool.getResource().ping();

所以推荐使用的代码规范是:

复制代码
执行命令如下:
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    //具体的命令
    jedis.executeCommand()
} catch (Exception e) {
    //如果命令有key最好把key也在错误日志打印出来,对于集群版来说通过key可以帮助定位到具体节点。
    logger.error(e.getMessage(), e);
} finally {
    //注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
    if (jedis != null) 
        jedis.close();
}

异常原因二: 业务并发量大,maxTotal确实设置小了!

举个例子:

一次命令时间(borrow|return resource + Jedis执行命令(含网络) )的平均耗时约为1ms,一个连接的QPS大约是1000,业务期望的QPS是50000,那么理论上需要的资源池大小是50000 / 1000 = 50个,实际maxTotal可以根据理论值合理进行微调。

异常原因三: Jedis连接还的太慢

例如Redis发生了阻塞(例如慢查询等原因),所有连接在超时时间范围内等待,并发量较大时,会造成连接池资源不足。

异常原因四: 其他问题

例如丢包、DNS、客户端TCP参数配置,具体可以参考:Jedis介绍及常见问题分析

异常原因五: 检查Redis的配置是否正确,IP端口【值得反思】

4、解决方案:

1、检查Redis的配置是否正确,IP端口【值得反思】

2、调整配置参数。但是,不要被异常的表象所迷惑,简单地认为连接池不够就盲目加大maxTotal,要具体问题具体分析。连接池参数优化可以参考:JedisPool资源池优化

3、客户端没有从连接池(最大maxTotal个)拿到可用Jedis连接造成的,简称连接泄露 (常见),所以推荐使用的代码规范是如下:

复制代码
执行命令如下:
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    //具体的命令
    jedis.executeCommand()
} catch (Exception e) {
    //如果命令有key最好把key也在错误日志打印出来,对于集群版来说通过key可以帮助定位到具体节点。
    logger.error(e.getMessage(), e);
} finally {
    //注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
    if (jedis != null) 
        jedis.close();
}

参考:Jedis常见异常汇总 | 程序猿DD

相关推荐
wespaul11 小时前
VeapAI 自然语言操作实战|第 05 篇:向量与召回——从知识条目到可检索资产
大数据·数据库·人工智能·milvus
一只鹿鹿鹿16 小时前
政务外网整体设计方案(PPT)
大数据·数据库·web安全·系统安全·流程图·政务
2603_9651481116 小时前
社区与学习资源:从入门到精通的API选品学习路径
数据库·人工智能·python·学习·数据挖掘
AI砖家17 小时前
安全进入 Agent Loop:2027 年 Coding Agent 的决胜点
数据库·安全·codex·vibecoding
wangqiaowq17 小时前
SQL server C盘空间占满的处理
数据库·sql
文人sec17 小时前
SQL基础入门笔记 | 从零基础到掌握核心查询语句
数据库·笔记·sql
数字新视界17 小时前
机房动环监控提升运维效率
大数据·服务器·数据库·动环监控系统·动力与环境监控系统
SelectDB技术团队17 小时前
冷热分层从建到验:Storage Policy 创建、表级与分区级绑定、SHOW TABLETS 验证的完整命令
大数据·数据库·elasticsearch·搜索引擎·数据分析·apache doris·冷热分层
lambo mercy19 小时前
Day3:结构化输出
java·数据库·oracle
派小心.19 小时前
小程序分享链路中来源参数的传递校验
大数据·前端·数据库·人工智能·小程序·数据分析