jedis连接集群报Could not get a resource from the pool错误

Caused by: orgspringframeworkdataredisRedisConnectionFailureException: Could not get a resource from the pool; nested exception is redisclientsjedisexceptionsJedisConnectionException: Could not get a resource from the pool

at orgspringframeworkdataredisconnectionjedisJedisExceptionConverterconvert(JedisExceptionConverterjava:67)

at orgspringframeworkdataredisconnectionjedisJedisExceptionConverterconvert(JedisExceptionConverterjava:41)

at orgspringframeworkdataredisPassThroughExceptionTranslationStrategytranslate(PassThroughExceptionTranslationStrategyjava:37)

at orgspringframeworkdataredisconnectionjedisJedisClusterConnectionconvertJedisAccessException(JedisClusterConnectionjava:3999)

at orgspringframeworkdataredisconnectionjedisJedisClusterConnectionsetEx(JedisClusterConnectionjava:717)

at orgspringframeworkdatarediscoreDefaultValueOperations 11doInRedis(DefaultValueOperationsjava:186)

at orgspringframeworkdatarediscoreRedisTemplateexecute(RedisTemplatejava:207)

at orgspringframeworkdatarediscoreRedisTemplateexecute(RedisTemplatejava:169)

at orgspringframeworkdatarediscoreAbstractOperationsexecute(AbstractOperationsjava:91)

at orgspringframeworkdatarediscoreDefaultValueOperationsset(DefaultValueOperationsjava:182)

at iorenrencommonutilsSuppleDataUtilsprovideIcc(SuppleDataUtilsjava:107)

at iorenrenmodulesjobtaskTaskIcctaskFour(TaskIccjava:242)

10 common frames omitted

Caused by: redisclientsjedisexceptionsJedisConnectionException: Could not get a resource from the pool

at redisclientsutilPoolgetResource(Pooljava:53)

at redisclientsjedisJedisPoolgetResource(JedisPooljava:226)

at redisclientsjedisJedisSlotBasedConnectionHandlergetConnectionFromSlot(JedisSlotBasedConnectionHandlerjava:66)

at redisclientsjedisJedisClusterCommandrunWithRetries(JedisClusterCommandjava:116)

at redisclientsjedisJedisClusterCommandrunWithRetries(JedisClusterCommandjava:141)

at redisclientsjedisJedisClusterCommandrunWithRetries(JedisClusterCommandjava:141)

at redisclientsjedisJedisClusterCommandrunWithRetries(JedisClusterCommandjava:141)

at redisclientsjedisJedisClusterCommandrunWithRetries(JedisClusterCommandjava:141)

at redisclientsjedisJedisClusterCommandrunBinary(JedisClusterCommandjava:60)

at redisclientsjedisBinaryJedisClustersetex(BinaryJedisClusterjava:268)

at orgspringframeworkdataredisconnectionjedisJedisClusterConnectionsetEx(JedisClusterConnectionjava:715)

18 common frames omitted

Caused by: redisclientsjedisexceptionsJedisConnectionException: javanetSocketTimeoutException: connect timed out

at redisclientsjedisConnectionconnect(Connectionjava:207)

at redisclientsjedisBinaryClientconnect(BinaryClientjava:93)

at redisclientsjedisBinaryJedisconnect(BinaryJedisjava:1767)

at redisclientsjedisJedisFactorymakeObject(JedisFactoryjava:106)

at orgapachecommonspool2implGenericObjectPoolcreate(GenericObjectPooljava:868)

at orgapachecommonspool2implGenericObjectPoolborrowObject(GenericObjectPooljava:435)

at orgapachecommonspool2implGenericObjectPoolborrowObject(GenericObjectPooljava:363)

at redisclientsutilPoolgetResource(Pooljava:49)

28 common frames omitted

Caused by: javanetSocketTimeoutException: connect timed out

at javanetDualStackPlainSocketImplwaitForConnect(Native Method)

at javanetDualStackPlainSocketImplsocketConnect(DualStackPlainSocketImpljava:85)

at javanetAbstractPlainSocketImpldoConnect(AbstractPlainSocketImpljava:350)

at javanetAbstractPlainSocketImplconnectToAddress(AbstractPlainSocketImpljava:206)

at javanetAbstractPlainSocketImplconnect(AbstractPlainSocketImpljava:188)

at javanetPlainSocketImplconnect(PlainSocketImpljava:172)

at javanetSocksSocketImplconnect(SocksSocketImpljava:392)

at javanetSocketconnect(Socketjava:589)

at redisclientsjedisConnectionconnect(Connectionjava:184)

35 common frames omitted

最近在本地测试通过springboot基础redis的方式连接redis集群，启动的时候没有报错。

到时当执行保存，查询到redis的 *** 作的时候，报上面的错误。

首先看到错误信息，先是connect timed out后，再出现的Could not get a resource from the pool错误。一开始排查这个错误，由于使用的是默认连接池，debug的时候，也看到有装载连接池，为啥报错呢。本地通过redis-manger工具，连接集群地址也可以连接访问。从日志也看不出还有其他的错误信息。

于是自己写了main方法直接 *** 作JedisCluster的方式来测试，出现的错误跟上面全文一样。用抓包工具wireshark过滤集群的地址，查看连接的消息也是正常的。

另外一个项目使用的reddison客户端，于是测试了deamo用reddison来连接集群地址，启动的时候，发现报如下错误

乖乖，恍然大悟；102871731地址是服务器的内网地址，本机是连不上内网地址的，只有通过外网地址连接。而我配置的是外网地址。然而，客户端在集群同步和心跳检查的时候，是拉取的集群信息，redis集群信息里面的节点的信息

配置的是内网地址。客户端就通过这个内网地址来同步信息了。

再次同wireshark过滤集群102871731，发现有大量的超时重传的包，也没有响应。

在使用 redis-cli 连接 redis 集群，进行数据 *** 作时，有报错

解决方法：

这种情况一般是因为启动 redis-cli 时没有设置集群模式所导致。

启动时使用 -c 参数来启动集群模式，命令如下：

使用redis-cli连接上redis其中一台

redis-cli -c -h xxx -p 7001

输入cluster info查看当前集群的状态

可以使用trib的check检测的集群状态

redis-tribrb check xxx:7001

[ERR] Not all 16384 slots are covered by nodes

如果出现以上的错误，可以尝试使用fix命令修复

redis-tribrb fix xxx:7001

修复完成之后，在使用trib的check命令查看状态

如果通过fix方式修复不了

pkill redis停止之前的redis进程

然后把aof，rdb，nodes节点文件删除，删除之前需要备份

然后启动各个redis节点

redis-server /usr/local/src/redis-324/redis_cluster/7000/redisconf

redis-server /usr/local/src/redis-324/redis_cluster/7001/redisconf

redis-server /usr/local/src/redis-324/redis_cluster/7002/redisconf

redis-server /usr/local/src/redis-324/redis_cluster/7003/redisconf

redis-server /usr/local/src/redis-324/redis_cluster/7004/redisconf

redis-server /usr/local/src/redis-324/redis_cluster/7005/redisconf

创建redis集群

redis-tribrb create --replicas 1 xxx:7000 xxx:7001 xxx:7002 xxx:7003 xxx:7004 xxx:7005

7

集群创建完成之后，再次连接redis查看集群状态，如图可以看到3主3从的redis服务已经启动完成

redis-cli -c -h xxx -p 7000

cluster info

cluster nodes

 日常我们使用redis 缓存时，经常会遇到各种各样的问题，其中redis 偶发性连接超时，是经常遇到的一个问题，下面介绍一下我们之前是如何处理的这个问题。

1、redis 服务监控

      通过监控工具，首先排查一下redis 服务端是否是超时，可以从服务器cpu ，内存使用情况，qps等判断server 端是否超时。如果server 侧没有问题，就需要排查客户端。如果server 侧存在问题，就需要排查服务器哪里出了问题，单机性能使用率太高是否可以升级成哨兵模式或者高可用集群模式。

2、redis 客户端排查

     首先查看业务日志，查看一下redis 使用情况是否是存在连接数占满或者创建失败的异常，如果存在，在客户端服务器，使用top 指令，查看使用率高的线程，然后jstack pid,查看当前线程的使用情况。如果出现大量的线程状态显示time_waiting 或者waiting 。则表示连接数一直没有释放，可以通过调整客户端配置的redis 连接池参数，比如配置max连接数和min连接数，time_out超时时间等等。

3、redis 热key排查

排查redis 热key,腾讯云或者阿里云服务器可以使用监控热key的工具。redis 40 以后，提供了—hotkey 指令，可以通过热key 指令来监控热key。如果发现异常热key,比如spring-redis-session的热key,存储的是一段时间戳，并且访问率非常高，qps 几十万/s。这时候需要考虑热key是否对业务产生影响，可以通过配置springsessionstore-type=none，关闭存储redis这时候热key访问量下降，业务key 可以正常访问。

通过以上方式，排查生产中遇到的redis 连接问题，可以排查线上遇到的问题，基本都可以解决掉。

redis集群角色切换java调用异常

一、Redis状态检查

唯一标记一个redis实例的是ip和端口，前端是用tcp方式来访问redis的，我们提供给应用访问的是一个ip+63379(一般使用63379) 端口。因此我们执行如下命令检查redis状态:

上面的role这个值一定是master的，只要保证vip在master上我们的Padis cache服务就是没有问题的，如果不通或者role的角色是slave，那就得继续查看是什么问题

二、两个redis的角色都是slave的问题

当两个主机都挂了或者我们自己不小心将两个redis停了，并且我们用下面的命令检查

/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} info replication

发现无论是vip还是另外的两个ip都是role:slave 的角色，这个时候需要对vip所在的主机执行slaveof no one 的 *** 作,将vip 所在的redis变成master,如:

/wls/wls81/redis/bin/redis-cli -h {vip} -p {port} -a {password} slaveof no one

三、sentinel的配置参数

我们的sentinel 配置文件里面有两个重要的配置

sentinel monitor pds_jks-core-prd 10339465 63379 1 -----------配置的ip和端口任何时候都需要是master的ip端口,切换的时候程序自动会改 。另外，红色所示部分pds_jks-core-prd为redis对外提供的主机名，一般Jedis在调用redis时会用到此名称。如果配置多个哨兵则一般要求此名称唯一标识

sentinel down-after-milliseconds pds_jks-core-prd 15000 ----------这个是sentinel连接master的超时时间，超过这个时间就认为master挂了，实现自动切换。这个默认是30秒，这个时间得调节好，大了会在真正出现故障的时候切换时间会长，小了有时候master由于持久化数据，繁忙不响应，会导致自动切换，实际只是瞬间不可用，现在认为设置为15秒为宜

四、AOF日志

这个日志记录了每一个写入命令或者删除命令的，这个对于我们审计功能是有用的，由于占用很多磁盘，默认我们是关闭的

如果开启会生成一个aof的文件在data文件中 如: /wls/apache/servers/pds_jks-core-prd/data

在redis运行中中开启：

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set appendonly yes

开启了可以查看日志，记录每一个命令，如有必要可以开启查完问题后关闭 同时说明一下

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set 可以在redis运行的时候设置多个它的参数

五、空闲连接的timeout

redis服务端不会自动断开客户端来的连接，redis服务端有设置客户端空闲连接超时时间，可用命令

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config get timeout

查看当前timeout时间，默认是0，就是不断开空闲的连接，如果不断开空闲的连接，就会造成redis连接过多

所以一般情况下可以设置为3600秒:

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set timeout 3600

也就是3600秒后将空闲的连接关闭掉 可以用下面的命令查看某个连接空闲了多久:

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} client list

六、监控redis执行的命令

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} monitor

上述这个monitor命令可以查看redis执行了什么命令，有时候查问题很有必要用到，我们可以知道那段时间redis执行了什么，从而进行我们的问题诊断。

七、key的查找与执行

/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} keys ""

keys这个命令查找所有的key，但是最好慎用，因为它很耗redis的性能，每个key都遍历一遍 也可以进行模糊匹配如： keys "send"

千万记住在生产环境上不能随便乱用，因为它会将redis性能耗尽，导致其他连接获取不到响应

/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} dbsize

dbsize 这个命令可以看到整一个redis里面有多少个key，当然和keys "" | wc -l结果是一样的。

当我们需要批量删除key值时可以用如下命令即可:

/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} keys "send" | xargs /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} del

我们需要将整个db都flush掉可以用:

/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a MamcCorePrd flushdb

/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a flushall

八、由于连接redis的客户端使用jedisPool

如果设置了

redispooltestOnBorrowREL=true

redispooltestOnReturnREL=true

这两个参数是说在或者pool中的连接和返回连接给pool的时候都需要检查一下连接的有用性，也就是ping一下这个redis是不是好的，

这样在高并发的时候，由于并发线程太多，ping *** 作相对线程启动来说很慢，因此，应用会堵在类似如下线程dump的地方

"[ACTIVE] ExecuteThread: '19' for queue: 'weblogickernelDefault (self-tuning)'" id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon

at jrockit/net/SocketNativeIOreadBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)

at jrockit/net/SocketNativeIOsocketRead(SocketNativeIOjava:32)

at java/net/SocketInputStreamsocketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStreamjava)

at java/net/SocketInputStreamread(SocketInputStreamjava:129)

at java/net/SocketInputStreamread(SocketInputStreamjava:90)

at redis/clients/util/RedisInputStreamfill(RedisInputStreamjava:109)

at redis/clients/util/RedisInputStreamreadByte(RedisInputStreamjava:45)

at redis/clients/jedis/Protocolprocess(Protocoljava:64)

at redis/clients/jedis/Protocolread(Protocoljava:131)

at redis/clients/jedis/Jedisping(Jedisjava:35)

at redis/clients/jedis/JedisPool$JedisFactoryvalidateObject(JedisPooljava:104)

at org/apache/commons/pool/impl/GenericObjectPooladdObjectToPool(GenericObjectPooljava:922)

at org/apache/commons/pool/impl/GenericObjectPoolreturnObject(GenericObjectPooljava:917)

^-- Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]

at redis/clients/util/PoolreturnResourceObject(Pooljava:29)

at redis/clients/util/PoolreturnResource(Pooljava:41)

at com/paic/icore/mams/common/jedis/util/RedisPoolCacheToolsrelease(RedisPoolCacheToolsjava:43)

虽然后面会自动恢复，不过导致应用响应缓慢解决方法是将该两个参数设置为false，并且定期检查：

testOnBorrowREL=false

testOnReturnREL=false

timeBetweenEvictionRunsMillis=60000 -------每隔60秒定期检查空闲连接

minEvictableIdleTimeMillis=120000 ---------连接在池中保持空闲而不被空闲连接回收器线程回收的最小时间值,单位毫秒

numTestsPerEvictionRun=-1 ----------空闲连接扫描时，每次最多扫描的连接数,一般设置为-1，全部扫描

设置成这样之后就不用每次都测试了，这样就提高了应用的性能

有时候由于持久化导致master变得缓慢，所以建议关闭master的持久化，让slave持久化

关闭持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save ""

开通持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save "900 1 300 10 60 10000"

关闭持久化后如果发生主备切换了，请将master的持久化关闭，slave的持久化开启

九、查询每秒执行的命令个数

十、单位时间内Redis执行的命令次数

项目中要用到redis，于是尝试通过springboot整合redis，redis集群采用3主3从，搭建方法参考： >

以上就是关于jedis连接集群报Could not get a resource from the pool错误全部的内容，包括:jedis连接集群报Could not get a resource from the pool错误、Redis集群报错：(error) MOVED 解决方法、redis集群如何解决重启不了的问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！