來源：行思錄 ，
liudanking.com/performance/一次非典型性-redis-阻塞總結/
南方逐漸進入一年中最好的時節，用戶也開始騷動起來。看了眼數據，活躍用戶已經double很遠，馬上triple了。
一日睡眼惺忪的清晨，正看着數據默默yy時候，線上開始告警…… MMP，用戶早上騷動的增長比想象好快呢。同事第一時間打開立體監控瞥了一眼，結合服務的錯誤日誌，很快把問題鎖定到了一個Redis實例（事實上，自從立體監控上線以後，基本上處理流程從以前的 < 80%時間定位問題 + 20%解決問題 > 變成了 < 少量時間確認問題 + 解決問題 >）。團隊處理效率還是挺快的，原因定位到AOF持久化：
這是當時的Redis配置：
127.0.0.1:6379> config get *append*
1) "no-appendfsync-on-rewrite"
2) "no"
3) "appendonly"
4) "yes"
5) "appendfsync"
6) "everysec"
從配置看，原因理論上就很清楚了：我們的這個Redis示例使用AOF進行持久化(appendonly)，appendfsync策略採用的是everysec刷盤。但是AOF隨着時間推移，文件會越來越大，因此，Redis還有一個rewrite策略，實現AOF文件的減肥，但是結果的冪等的。我們no-appendfsync-on-rewrite的策略是 no. 這就會導致在進行rewrite操作時，appendfsync會被阻塞。如果當前AOF文件很大，那麼相應的rewrite時間會變長，appendfsync被阻塞的時間也會更長。
這不是什麼新問題，很多開啓AOF的業務場景都會遇到這個問題。解決的辦法有這麼幾個：
將no-appendfsync-on-rewrite設置爲yes. 這樣可以避免與appendfsync爭用文件句柄，但是在rewrite期間的AOF有丟失的風險。
給當前Redis實例添加slave節點，當前節點設置爲master, 然後master節點關閉AOF，slave節點開啓AOF。這樣的方式的風險是如果master掛掉，尚沒有同步到salve的數據會丟失。
我們採取了折中的方式：在master節點設置將no-appendfsync-on-rewrite設置爲yes，同時添加slave節點。
理論上，問題應該解決了吧？啊蛤，的確是理論上。
修改後第一天，問題又出現了。驚不驚喜，意不意外？
於是，小夥伴又重新複習了一下當時出問題時候的Redis日誌：
有兩個點比較可以：
前幾條AOF日誌告警日誌發生在晚上3~5點之間，而那個時候，我們整個系統負載是非常低的。
清晨的告警日誌不是某一個Redis實例告警，而是該機器上的所有Redis實例都在告警。
在這種百思不得騎姐的情況下，結合歷史上被坑的經驗，我們99%斷定是我們使用的雲主機存在問題。
這個問題有可能是宿主機超售太多導致單個租戶實際能使用到的雲盤IO比標稱值低，也有可能是租戶隔離做得不好，導致壞鄰居過度佔用IO影響其他租戶。
這個很好理解：我們使用的是阿里雲的雲SSD，而阿里雲目前的架構還沒有做到計算和存儲分離，即計算和存儲的網絡IO是共享的。
當然目前這個問題還沒有實錘，我們也還在跟阿里雲積極溝通解決。同時爲了避免給自己惹麻煩，我還是留了1%的其他可能性。
ClickHouse在趣頭條中的實戰PPT
內存耗盡後Redis會發生什麼
面試官：請你講講Redis官方提供的高可用方案？
戳這兒
本文分享自微信公衆號 - 俠夢的開發筆記（xmdevnote）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。