大家好，我是小趴菜，這一天過的是真令人頭大呀，本來是接手一個同事維護(hù)的老項(xiàng)目就已經(jīng)頭疼的不行了，結(jié)果現(xiàn)在有大量的用戶反映應(yīng)線上服務(wù)不可用。

沒辦法，只能硬著頭皮上了，我打開了服務(wù)器上的日志，就發(fā)現(xiàn)大量的錯誤日志，報的都是 redis的 Connection reset by peer錯誤，我也不知道是什么意思，只能打開百度翻譯下，翻譯才知道這是重置連接的意思，很納悶，為什么redis會重置連接，后面找了點(diǎn)資料，說是有以下幾個原因?qū)е碌?/p>

• 1：服務(wù)器的并發(fā)連接數(shù)太多，超出了服務(wù)器的承載量，所以服務(wù)器會關(guān)閉一些連接
• 2：redis的TimeOut設(shè)置的太短

沒辦法一個一個的排查了

首先看了下項(xiàng)目配置，rdis使用的lettuce相關(guān)的線程池，但是設(shè)置了最大連接數(shù)有1000，那是不是有可能這個原因?qū)е碌哪兀?/p>

redis:
  host: 127.0.0.1
  port: 6379
  password: 
  database: 0
  timeout: 20000
  lettuce:
    # 關(guān)閉超時時間
    shutdown-timeout: 1000
    pool:
      # 連接池最大連接數(shù)（使用負(fù)值表示沒有限制）
      max-active: 1000
      # 連接池中最大空閑連接
      max-idle: 200
      # 連接池中最大阻塞等待時間（使用負(fù)值標(biāo)識沒有限制）
      max-wait: 3000
      # 連接池中的最小空閑連接
      min-idle: 20

也只能試試了，將最大連接數(shù)調(diào)低，但是最后發(fā)現(xiàn)沒有解決這個問題，所以第一點(diǎn)我們可以排除了

所以現(xiàn)在只能看下是不是超時時間太短，但是我就在想，為什么會有這么多連接超時。

在這里我真的是想扇自己的心都有，一定要仔細(xì)看日志，一定要仔細(xì)看日志，一定要仔細(xì)看日志

在日志中已經(jīng)很清楚的打印出了具體的方法了，進(jìn)入這個對應(yīng)的方法才知道，這個方法有將所有地市的數(shù)據(jù)封裝成一個列表，然后存儲到redis中，然后后續(xù)直接從這個redis中查詢出來。

可問題就是這個地市的數(shù)據(jù)太多了，有幾萬條，估計(jì)是前同事為了省事就直接一股腦的全放到一個key中了。那么這時候這個key就是個大key

這時候很多線程來查詢這個key，導(dǎo)致查詢的時間太久了，也就一直報連接超時了。 先不管，先把這個問題解決先，既然數(shù)據(jù)多，那我就分頁查詢數(shù)據(jù)庫，我就不用redis了。加了索引其實(shí)查詢也很快。

發(fā)布上線之后觀察了一段時間，發(fā)現(xiàn)再也沒有這個問題了。所以可以肯定就是因?yàn)檫@個大key的原因才導(dǎo)致的

思考

因?yàn)楫?dāng)時用戶并發(fā)量較高，導(dǎo)致redis的連接數(shù)被占滿，后續(xù)有大量的用戶來申請redis連接，導(dǎo)致有些連接被強(qiáng)制關(guān)閉，也因?yàn)椴樵兊氖且粋€大key，所以導(dǎo)致線程的redis一直報連接超時

所以在使用redis做緩存時候一定要仔細(xì)小心，不能存儲大key，你可以將key進(jìn)行查分，或者是分頁查詢。

到此這篇關(guān)于線上Redis一直報連接超時該如何解決的文章就介紹到這了,更多相關(guān)Redis連接超時內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論