知識星球（點選上方公眾號，可快速關註）
來源：行思錄 ，
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%的其他可能性。
參考資料
-
Redis相關—Redis持久化
https://yemengying.com/2016/04/24/Redis-Persistence/
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
