我麻了，线上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进行查分，或者是分页查询。