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

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

1、首先和負(fù)責(zé)redis同學(xué)排查，先排除redis本身的問題

2、服務(wù)自查

異常分布

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

Redis負(fù)載

查看redis集群是否有節(jié)點(diǎn)負(fù)載過高，比如以常規(guī)經(jīng)驗(yàn)看來的80%。

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

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

慢請(qǐng)求

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

客戶端原因

常見的幾個(gè)問題原因有：

• CPU

• 進(jìn)程GC

• 網(wǎng)絡(luò)

• 容器宿主機(jī)

CPU

觀察機(jī)器或容器的CPU：

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

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

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

進(jìn)程GC

頻繁的GC或者GC耗時(shí)過長會(huì)讓線程無法及時(shí)被調(diào)度到讀取redis響應(yīng)。

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

然后也要對(duì)比和之前正常時(shí)是否存在明顯上升。

網(wǎng)絡(luò)

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

我的問題定位到這里其實(shí)已經(jīng)發(fā)現(xiàn)了，容器的TCP重傳率非常高，有些甚至達(dá)到了0.6%，咨詢?nèi)萜鞯耐陆ㄗh重啟容器，重啟之后立刻解決問題。

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

容器宿主機(jī)

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

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

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