7月2號10點後，剛好某個負責的服務發生大量的redis連線超時的異常(redis.clients.jedis.exceptions.JedisConnectionException)，由於本身的資料庫查詢快取在redis中2分鐘，並且未做降級措施，而且本身不能做限流處理，而且隨著午高峰的時間流量在飆升，並且從10點開始的2000的QPS，在11點達到高峰的13000QPS。
好在只是redis超時導致的某個查詢的失效，並不會導致整個主鏈路的流程不可用，所以接下來是怎麼快速發現和解決問題。
1、首先和負責redis同學排查，先排除redis本身的問題
2、服務自查
異常分佈
如果監控可以看到單機維度的話，切換到單機維度檢視異常是否均勻分佈，如果分佈不均勻，只是少量的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做級快取也是一個比較合理的方案。平時開發中要充分考慮資料的時效性來做對應的設計。