這篇文章給大家分享的是有關(guān)redis超時排查的示例分析的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
10年積累的成都做網(wǎng)站、成都網(wǎng)站設計經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先做網(wǎng)站后付款的網(wǎng)站建設流程，更有塔什庫爾干塔吉克免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
前兩天的工作中，突然收到告警，提示 Redis 掛了，同時大群也在說某某 Redis 連接超時了。當初以為是有大問題，誰知道它過了一會兒就恢復了。那個時候，我登上服務器，查看監(jiān)控。第一時間看看 QPS：
可以看到 QPS 并不高，但是中間有段時間沒取到數(shù)據(jù)是怎么回事？那么繼續(xù)看看 Redis 的 cpu 使用率：
可以看到 cpu 已經(jīng)飽和，這也就能解釋為何斷圖了，因為 redis 是單線程，在使用 cpu 100% 以后，就無法處理其他的命令了，zabbix 也就無法執(zhí)行 info 命令取 qps 了。那么已經(jīng)知道是 cpu 使用飽和造成的問題，那么到底是什么原因呢？那么繼續(xù)查看，cpu 使用高的這段時間有沒有慢日志：
好像也不是導致 cpu 高的兇手，這就難排查了，這個實例是 1 主 1 從。那么我看看從庫的 cpu 使用情況看看：
臥槽，怎么回事，從庫沒有使用的怎么 cpu 也用到了 74%？這不科學?。抗芩?，看看從庫有沒有慢日志：
臥槽，怎么回事？從庫沒人使用啊。看看是否只讀：
重慶分公司
重慶分公司
127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103>
看來是只讀的，這把我給整懵了。最后突然想到是主庫在這個點有 big key 過期，而主庫過期 key 操作慢是不會記錄慢日志的，從庫的 key 過期是由主庫發(fā)起 DEL 指令刪除的。這時從庫就會記錄慢日志，從上面慢日志可以看到這些 DEL 操作最大的 335ms，怪不得會有應用連接超時的。
再使用命令 info commandstats 看看：
感謝各位的閱讀！關(guān)于“Redis超時排查的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
