线上Redis一直报连接超时该如何解决

大家好，我是小趴菜，这一天过的是真令人头大呀，本来是接手一个同事维护的老项目就已经头疼的不行了，结果现在有大量的用户反映应线上服务不可用。

没办法，只能硬着头皮上了，我打开了服务器上的日志，就发现大量的错误日志，报的都是 redis的 Connection reset by peer错误，我也不知道是什么意思，只能打开百度翻译下，翻译才知道这是重置连接的意思，很纳闷，为什么redis会重置连接，后面找了点资料，说是有以下几个原因导致的

• 1：服务器的并发连接数太多，超出了服务器的承载量，所以服务器会关闭一些连接
• 2：redis的TimeOut设置的太短

没办法一个一个的排查了

首先看了下项目配置，rdis使用的lettuce相关的线程池，但是设置了最大连接数有1000，那是不是有可能这个原因导致的呢？

redis:
  host: 127.0.0.1
  port: 6379
  password: 
  database: 0
  timeout: 20000
  lettuce:
    # 关闭超时时间
    shutdown-timeout: 1000
    pool:
      # 连接池最大连接数（使用负值表示没有限制）
      max-active: 1000
      # 连接池中最大空闲连接
      max-idle: 200
      # 连接池中最大阻塞等待时间（使用负值标识没有限制）
      max-wait: 3000
      # 连接池中的最小空闲连接
      min-idle: 20

也只能试试了，将最大连接数调低，但是最后发现没有解决这个问题，所以第一点我们可以排除了

所以现在只能看下是不是超时时间太短，但是我就在想，为什么会有这么多连接超时。

在这里我真的是想扇自己的心都有，一定要仔细看日志，一定要仔细看日志，一定要仔细看日志

在日志中已经很清楚的打印出了具体的方法了，进入这个对应的方法才知道，这个方法有将所有地市的数据封装成一个列表，然后存储到redis中，然后后续直接从这个redis中查询出来。

可问题就是这个地市的数据太多了，有几万条，估计是前同事为了省事就直接一股脑的全放到一个key中了。那么这时候这个key就是个大key

这时候很多线程来查询这个key，导致查询的时间太久了，也就一直报连接超时了。 先不管，先把这个问题解决先，既然数据多，那我就分页查询数据库，我就不用redis了。加了索引其实查询也很快。

发布上线之后观察了一段时间，发现再也没有这个问题了。所以可以肯定就是因为这个大key的原因才导致的

思考

因为当时用户并发量较高，导致redis的连接数被占满，后续有大量的用户来申请redis连接，导致有些连接被强制关闭，也因为查询的是一个大key，所以导致线程的redis一直报连接超时

所以在使用redis做缓存时候一定要仔细小心，不能存储大key，你可以将key进行查分，或者是分页查询。

到此这篇关于线上Redis一直报连接超时该如何解决的文章就介绍到这了,更多相关Redis连接超时内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论