Redis 超時排查

忽然收到告警，提示redis掛了，同時大羣也在說某某redis鏈接超時了，過了一下子就恢復了。這時登上服務器，查看監控。首先看看qps：

能夠看到qps並不高，可是中間有段時間沒取到數據是怎麼回事？那麼繼續看看redis的cpu使用率：

能夠看到cpu已經飽和，這也就能解釋爲什麼斷圖了，由於redis是單線程，在使用cpu 100%之後，就沒法處理其餘的命令了，zabbix也就沒法執行info命令取qps了。那麼已經知道是cpu使用飽和形成的問題，那麼究竟是什麼緣由呢？那麼繼續查看，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過時是由主庫發起DEL指令刪除的。這時從庫就會記錄慢日誌，從上面慢日誌能夠看到這些DEL操做最大的335ms，怪不得會有應用鏈接超時的。

再使用命令info commandstats看看：

總結：

redis因爲的單線程，單個耗時過大命令，致使阻塞其餘命令。key儘可能的控制大小。那麼key的過時最好是手動寫腳本刪除，好比刪除大set鍵，使用sscan命令，每次掃描集合中500個元素，再用srem命令每次刪除一個鍵。固然還能夠合理的設置過時時間，設置過時時間不在業務的高峯期，業務高峯期通常天天都在同一時間，那麼過時時間設置整數天+8個小時左右就是凌晨了，就避免了在業務高峯期過時。固然還能夠使用Redis 4.0，Redis 4.0的Lazy Free特性已經很好的解決該問題，不過相關參數默認是不開啓的，應該還不是很成熟。