在我們前幾天的工作中，我們突然接到了一個告警，提示我們的 Redis 已經崩潰了，而且還有許多人在討論某個 Redis 的連接超時。當初以為是有大問題，誰知道它過了一會兒就恢復了。那時候，我登上伺服器，查看監控。第一時間看看 QPS：
#
可以看到 QPS 不高，但中間有一段時間沒拿到資料是怎麼回事？那麼繼續看看 Redis 的 cpu 使用率：
可以看到cpu 已經飽和，這也就能解釋為何斷圖了，因為redis 是單線程，在使用cpu 100% 以後，就無法處理其他的指令了，zabbix 也就無法執行info命令取qps 了。那麼已經知道是 cpu 使用飽和造成的問題，那麼到底是什麼原因呢？那麼繼續查看，cpu 使用高的這段時間有沒有慢日誌：
#
這似乎不是導致 CPU 佔用率高的罪魁禍首，所以很難檢查。這個範例是一個主節點和一個從屬節點。那我看看從庫的 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 過期是由主庫發起 DEL 指令刪除的。這時從庫就會記錄慢日誌，從上面慢日誌可以看到這些 DEL 操作最大的 335ms，怪不得會有應用連線逾時的。
再用指令 info commandstats 看看：
以上是Redis超時排查的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
