場景：隨著線上redis所儲存的key值原來越多，偶爾會遇到某個查詢耗時很長的問題，剛開始並沒有重視，隨著業務量的增加和某些人對redis操作不規範，導致線上查詢慢的發生概率越來越高，所以領導就找我和運維的人一起查詢此類問題和解決辦法，也順便記錄一下排查過程。

    排查如下：

1，慢查詢。因為發生頻率很高，跟著運維一起分析了慢查詢日誌，發現沒有要查的那條耗時很長的記錄，配置的慢查詢為0.1毫秒，根據慢查詢的原理，說明redis單執行緒處理此條記錄時在記憶體執行時耗時沒有超過0.1毫秒。

2，排隊等待時間，查詢耗時的總時間=排隊等待時間+執行時間+返回耗時，返回時間可以忽略不計，那有可能是排隊等待時間耗時過長造成的，根據redis監控，當時連線數還沒有達到配置的最大連線數，還是不能說明問題，這時又一個慢查詢報出來，快速檢視redis排隊等待的連線數，還是很少，慢查詢也沒有，那說明等待時間也可以排除啦

陷入沉思.......

突然想到redis的RDB備份時，當資料量比較大時，會導致伺服器停止幾百毫秒或者1秒.........

3，讓運維人員看了一下，現在線上redis的備份方式，果然是RDB，而且還是預設的

還只能是猜測，商量了一個解決辦法，線上redis採用的是哨兵，1主2從，RDB發生在1主上，修改RDB發生的機器或者RDB修改為AOF，修改過後，暫時沒發現有查詢耗時很長的操作。