连接池无法获取到连接或获取连接超时
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
对于这类问题的原因有几类，可以根据以下一一进行排查
连接配置错误
Jedis连接池配置不可用，redis.host或redis.ip或redis.password 配置有误，手动检查配置是否都配置正确。
本地连接池连接数达到最大
连接池中有配置最大连接数maxTotal，本地连接使用达到最大连接数maxTotal。在访问客户端上通过netstat -an | grep 6379 | grep EST | wc -l 查看客户端链接数目，如果接近maxTotal, 说明本地连接池资源已经有过耗尽或者正在耗尽。
服务端连接数达到最大
服务端连接数已经超过最大值maxclients，单机的maxclients默认是10000，可以通过redis-cli登录服务端，使用info 命令查看当前连接数。
$redis-cli -h 10.1**.2.*0 -p 6379
10.1**.2.*0:6379> info clients
# Clients
connected_clients:1004
client_longest_output_list:0
client_biggest_input_buf:1
blocked_clients:0
10.1**.2.*0:6379>
当服务端连接数达到最大，可以通过命令client list，列出连接数，查看age=130222 idle=130222，这两值表示连接存活的时间和已经空闲的时间。
假如有IP的连接数过大，有可能是客户端连接使用不规范导致连接泄露。
网络问题
可以通过客户端工具redis-cli -h ${IP} -p ${port} -a ${pwd}，连接成功后，简单执行set mykey-i i, del mykey-i 命令，测试redis是否可用。
或者telnet host 6379进行连接，执行多次简单set del命令测试。
redis连接代码检查
获取JedisPool连接池中的jedis，使用jedis操作redis，每次getResource之后需要调用returnResource或者close进行归还，可以查看代码在使用完jedis之后是否returnResource，如果没有归还，则非常有可能产生连接泄露。
检查是否发生nf_conntrack丢包
通过dmesg检查客户端是否有异常
nf_conntrack: table full, dropping packet
如果发生nf_conntract丢包可以通过修改设置sysctl -w net.netfilter.nf_conntrack_max=120000
检查是否TIME_WAIT问题
通过ss -s 查看time wait链接是否过多
[root@localhost ~]# ss -s
Total: 314 (kernel 4877)
TCP: 32 (estab 3, closed 1, orphaned 0, synrecv 0, timewait 0/0), ports 0
Transport Total IP IPv6
* 4877 - -
RAW 1 0 1
UDP 2 1 1
TCP 31 13 18
INET 34 14 20
FRAG 0 0 0
如果TIME_WAIT过多可以修改以下参数
sysctl -w net.ipv4.tcp_max_tw_buckets=180000
sysctl -w net.ipv4.tcp_tw_recycle=1
linux文件系统句柄数过小
设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你
无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
抓包分析
如果按照上面排查之后还有问题可以通过抓包进行分析。
抓包命令为sudo tcpdump -i eth0 tcp and port 6379 -n -nn -s 74 -w redis.cap。
---------------------
作者：常乐_smile
来源：CSDN
原文：https://blog.csdn.net/li396864285/article/details/78623950
版权声明：本文为博主原创文章，转载请附上博文链接！