Redis中出現(xiàn)大量連接超時如何解決

今天就跟大家聊聊有關(guān)Redis中出現(xiàn)大量連接超時如何解決，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

排查思路

查看異常分布

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

誒，這就很舒服了，這一下子就找到了問題，只有幾臺機器異常非常高。

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

Redis情況

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

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

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

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

嗯... ...

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

CPU

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

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

再看看CPU是不是存在限流，或者存在密集的限流、長時間的限流。

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

GC停頓

得嘞，運維這次沒作死。

再看看GC咋樣。

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

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

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

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

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

網(wǎng)絡(luò)

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

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

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

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

看完上述內(nèi)容，你們對Redis中出現(xiàn)大量連接超時如何解決有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。