[[395813]]

之前負(fù)責(zé)的一個(gè)服務(wù)總是在高峰時(shí)刻和壓測(cè)發(fā)生大量的redis連接超時(shí)的異常redis.clients.jedis.exceptions.JedisConnectionException，根據(jù)原有的業(yè)務(wù)規(guī)則，首先會(huì)從數(shù)據(jù)庫查詢，然后緩存到redis中，超時(shí)時(shí)間設(shè)置為3分鐘。

并且由于業(yè)務(wù)的特性，本身未做降級(jí)、限流等處理措施，而在巔峰的QPS基本上快達(dá)到20000的樣子，雖然這個(gè)現(xiàn)象只是單純的一個(gè)異常，并不會(huì)導(dǎo)致整個(gè)主鏈路的流程不可用，但是我們還是要找出問題的原因并且解決。

首先我們找到負(fù)責(zé)Redis同學(xué)排查，他們告訴我Redis現(xiàn)在很穩(wěn)定，沒有問題，以前現(xiàn)在未來都不會(huì)出問題，出了問題肯定是你們自己的問題。

... ...

說的好有道理，我竟無力反駁，真是讓人兩個(gè)頭一個(gè)大。

這樣的話，我們就只能去找找自身的原因了。

排查思路

查看異常分布

首先根據(jù)經(jīng)驗(yàn)，我們看看自己的服務(wù)器的情況，看下異常到底出現(xiàn)在哪些機(jī)器，通過監(jiān)控切換到單機(jī)維度，看看異常是否均勻分布，如果分布不均勻，只是少量的host特別高，基本可以定位到出現(xiàn)問題的機(jī)器。

誒，這就很舒服了，這一下子就找到了問題，只有幾臺(tái)機(jī)器異常非常高。

不過不能這樣，我們繼續(xù)說排查思路......

Redis情況

再次按照經(jīng)驗(yàn)，雖然負(fù)責(zé)redis的同學(xué)說redis賊穩(wěn)定巴拉巴拉，但是我們本著懷疑的態(tài)度，不能太相信他們說的話，這點(diǎn)很重要，特別是工作中，同學(xué)們，不要?jiǎng)e人說啥你就信啥，要本著柯南的精神，發(fā)生命案的時(shí)候每個(gè)人都是犯罪嫌疑人，當(dāng)然你要排除自己，堅(jiān)定不移的相信這肯定不是我的鍋！

好了，我們看看redis集群是否有節(jié)點(diǎn)負(fù)載過高，比如以常規(guī)經(jīng)驗(yàn)看來的80%可以作為一個(gè)臨界值。

如果有一個(gè)或少量節(jié)點(diǎn)超過，則說明可能存在熱key問題，如果大部分節(jié)點(diǎn)都超過，則說明存在redis整體壓力大問題。

另外可以看看是否有慢請(qǐng)求的情況，如果有慢請(qǐng)求，并且時(shí)間發(fā)生問題的時(shí)間匹配，那么可能是存在大key的問題。

嗯... ...

redis同學(xué)說的沒錯(cuò)，redis穩(wěn)如老狗。

CPU

我們假設(shè)自己還是很無助，還是沒發(fā)現(xiàn)問題在哪兒，別急，接著找找別人的原因，看看CPU咋樣，可能運(yùn)維偷偷滴給我們把機(jī)器配置給整差了。

我們看看CPU使用率多高，是不是超過80%了，還是根據(jù)經(jīng)驗(yàn)，我們之前的服務(wù)一般高峰能達(dá)到60%就不錯(cuò)了。

再看看CPU是不是存在限流，或者存在密集的限流、長(zhǎng)時(shí)間的限流。

如果存在這些現(xiàn)象，應(yīng)該就是運(yùn)維的鍋，給我們機(jī)器資源不夠啊。

GC停頓

得嘞，運(yùn)維這次沒作死。

再看看GC咋樣。

頻繁的GC、GC耗時(shí)過長(zhǎng)都會(huì)讓線程無法及時(shí)讀取redis響應(yīng)。

這個(gè)數(shù)字怎么判斷呢？

通常，我們可以這樣計(jì)算，再次按照我們一塌糊涂的經(jīng)驗(yàn)，每分鐘GC總時(shí)長(zhǎng)/60s/每分鐘GC個(gè)數(shù)，如果達(dá)到ms級(jí)了，對(duì)redis讀寫延遲的影響就會(huì)很明顯。

為了穩(wěn)一手，我們也要對(duì)比下和歷史監(jiān)控級(jí)別是否差不多一致。

好了，打擾了，我們繼續(xù)。

網(wǎng)絡(luò)

網(wǎng)絡(luò)這塊我們主要看TCP重傳率，這個(gè)基本在大點(diǎn)的公司都有這塊監(jiān)控。

TCP重傳率=單位時(shí)間內(nèi)TCP重傳包數(shù)量/TCP發(fā)包總數(shù)

我們可以把TCP重傳率視為網(wǎng)絡(luò)質(zhì)量和服務(wù)器穩(wěn)定性的一個(gè)只要衡量指標(biāo)。

還是根據(jù)我們的經(jīng)驗(yàn)，這個(gè)TCP重傳率越低越好，越低代表我們的網(wǎng)絡(luò)越好，如果TCP重傳率保持在0.02%（以自己的實(shí)際情況為準(zhǔn)）以上，或者突增，就可以懷疑是不是網(wǎng)絡(luò)問題了。

比如這張圖一樣，要是和心電圖一樣，基本上網(wǎng)絡(luò)問題就沒跑了。

容器宿主機(jī)

有一些機(jī)器有可能是虛擬機(jī)，CPU的監(jiān)控指標(biāo)可能不準(zhǔn)確，特別是對(duì)于IO密集型的情況會(huì)有較大差異。可以通用其他手段來查詢宿主機(jī)的情況。

最后

根據(jù)一系列的騷操作，我們根據(jù)定位到的機(jī)器然后排查了一堆情況，最終定位到是網(wǎng)絡(luò)問題，有單獨(dú)的幾臺(tái)機(jī)器在高峰時(shí)期TCP重傳率賊高，最后根據(jù)運(yùn)維提供的解決方案：【重啟有問題的機(jī)器】，我們很順利的就解決了這個(gè)問題。

但是，這畢竟是治標(biāo)不治本的辦法，最終怎么解決的？

在我的另外一篇文章我有寫到了，沒人告訴過你更復(fù)雜的緩存穿透怎么解決