7月2號10點后，剛好某個負責的服務發(fā)生大量的redis連接超時的異常(redis.clients.jedis.exceptions.JedisConnectionException)，由于本身的數(shù)據(jù)庫查詢緩存在redis中2分鐘，并且未做降級措施，而且本身不能做限流處理，而且隨著午高峰的時間流量在飆升，并且從10點開始的2000的QPS，在11點達到高峰的13000QPS。

好在只是redis超時導致的某個查詢的失效，并不會導致整個主鏈路的流程不可用，所以接下來是怎么快速發(fā)現(xiàn)和解決問題。

1、首先和負責redis同學排查，先排除redis本身的問題

2、服務自查

異常分布

如果監(jiān)控可以看到單機維度的話，切換到單機維度查看異常是否均勻分布，如果分布不均勻，只是少量的host特別高，基本可以定位到出現(xiàn)問題的機器

Redis負載

查看redis集群是否有節(jié)點負載過高，比如以常規(guī)經驗看來的80%。

• 如果有一個或少量節(jié)點超過，則說明存在「熱key」問題。

• 如果大部分節(jié)點都超過，則說明存在「redis整體壓力大」問題。

慢請求

查看監(jiān)控，如果有慢請求的時間和發(fā)生問題的時間匹配，則可能存在「大key」問題

客戶端原因

常見的幾個問題原因有：

• CPU

• 進程GC

• 網絡

• 容器宿主機

CPU

觀察機器或容器的CPU：

• CPU （100%）是否接近或超過80%

• CPU限流是否存在密集的限流 或者長時間的限流

如果存在這些現(xiàn)象，應該是「計算資源不足」的問題

進程GC

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

通常是用每分鐘GC總時長/60s/每分鐘GC個數(shù)，如果達到ms級了，對redis讀寫延遲的影響就會很明顯。

然后也要對比和之前正常時是否存在明顯上升。

網絡

度量網絡質量一般可以看TCP重傳率的監(jiān)控，這個比率越低越好。如果TCP重傳率保持在0.02%（以自己的實際情況為準）以上，或者突增，可以定位到是否是「網絡問題」。

我的問題定位到這里其實已經發(fā)現(xiàn)了，容器的TCP重傳率非常高，有些甚至達到了0.6%，咨詢容器的同事建議重啟容器，重啟之后立刻解決問題。

繼續(xù)說排查思路。

容器宿主機

通過監(jiān)控查看容器宿主機的CPU情況，有一些可能機器是虛擬機的情況，CPU的監(jiān)控指標可能不準確，特別是對于io密集型的情況會有較大差異?？梢酝ㄓ肙PS提供的其他手段來查詢。

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

而且原來的歷史代碼本身也有一點小問題，這些緩存的數(shù)據(jù)其實大半年都不會變分擔分的，完全不需要redis緩存，內存級別的緩存就足夠了，或者說內存緩存+redis做級緩存也是一個比較合理的方案。平時開發(fā)中要充分考慮數(shù)據(jù)的時效性來做對應的設計。