突然收到告警，提示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特性已經很好的解決該問題，不過相關參數默認是不開啟的，應該還不是很成熟。