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做級快取也是一個比較合理的方案，平時開發中要充分考慮資料的時效性來做對應的設計，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/56946.html
標籤：Java