場景：隨着線上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，修改過後，暫時沒發現有查詢耗時很長的操作。