QPS過萬，redis大量鏈接超時怎麼解決？

7月2號10點後，恰好某個負責的服務發生大量的redis鏈接超時的異常(redis.clients.jedis.exceptions.JedisConnectionException)，因爲自己的數據庫查詢緩存在redis中2分鐘，而且未作降級措施，並且自己不能作限流處理，並且隨着午高峯的時間流量在飆升，而且從10點開始的2000的QPS，在11點達到高峯的13000QPS。

​ 好在只是redis超時致使的某個查詢的失效，並不會致使整個主鏈路的流程不可用，因此接下來是怎麼快速發現和解決問題。

一、首先和負責redis同窗排查，先排除redis自己的問題

二、服務自查

異常分佈

若是監控能夠看到單機維度的話，切換到單機維度查看異常是否均勻分佈，若是分佈不均勻，只是少許的host特別高，基本能夠定位到出現問題的機器

Redis負載

查看redis集羣是否有節點負載太高，好比以常規經驗看來的80%。

• 若是有一個或少許節點超過，則說明存在「熱key」問題。
• 若是大部分節點都超過，則說明存在「redis總體壓力大」問題。

慢請求

查看監控，若是有慢請求的時間和發生問題的時間匹配，則可能存在「大key」問題

客戶端緣由

常見的幾個問題緣由有：

• CPU
• 進程GC
• 網絡
• 容器宿主機

CPU

觀察機器或容器的CPU：

• CPU （100%）是否接近或超過80%
• CPU限流是否存在密集的限流 或者長時間的限流

若是存在這些現象，應該是「計算資源不足」的問題

進程GC

頻繁的GC或者GC耗時過長會讓線程沒法及時被調度到讀取redis響應。

一般是用每分鐘GC總時長/60s/每分鐘GC個數，若是達到ms級了，對redis讀寫延遲的影響就會很明顯。

而後也要對比和以前正常時是否存在明顯上升。

網絡

度量網絡質量通常能夠看TCP重傳率的監控，這個比率越低越好。若是TCP重傳率保持在0.02%（以本身的實際狀況爲準）以上，或者突增，能夠定位到是不是「網絡問題」。

個人問題定位到這裏其實已經發現了，容器的TCP重傳率很是高，有些甚至達到了0.6%，諮詢容器的同事建議重啓容器，重啓以後馬上解決問題。

繼續說排查思路。

容器宿主機

經過監控查看容器宿主機的CPU狀況，有一些可能機器是虛擬機的狀況，CPU的監控指標可能不許確，特別是對於io密集型的狀況會有較大差別。能夠通用OPS提供的其餘手段來查詢。

因爲保密性的問題，問題的截圖是不能放的，可是這個事情其實也是敲響一個警鐘，熔斷限流降級措施在關鍵性的鏈路必定要保證有，重要的事情說3遍，要有X3！

並且原來的歷史代碼自己也有一點小問題，這些緩存的數據其實大半年都不會變分擔分的，徹底不須要redis緩存，內存級別的緩存就足夠了，或者說內存緩存+redis作級緩存也是一個比較合理的方案。平時開發中要充分考慮數據的時效性來作對應的設計。

放鬆圖