Redis中出現大量連接超時如何解決

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

排查思路

查看異常分布

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

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

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

Redis情況

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

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

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

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

嗯... ...

redis同學說的沒錯，redis穩如老狗。

CPU

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

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

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

如果存在這些現象，應該就是運維的鍋，給我們機器資源不夠啊。

GC停頓

得嘞，運維這次沒作死。

再看看GC咋樣。

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

這個數字怎么判斷呢？

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

為了穩一手，我們也要對比下和歷史監控級別是否差不多一致。

好了，打擾了，我們繼續。

網絡

網絡這塊我們主要看TCP重傳率，這個基本在大點的公司都有這塊監控。

TCP重傳率=單位時間內TCP重傳包數量/TCP發包總數

我們可以把TCP重傳率視為網絡質量和服務器穩定性的一個只要衡量指標。

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

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