分析一次非典型性Redis阻塞

這篇文章主要講解了“分析一次非典型性Redis阻塞”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“分析一次非典型性Redis阻塞”吧！

南方逐漸進入一年中最好的時節(jié)，用戶也開始騷動起來?？戳搜蹟?shù)據(jù)，活躍用戶已經(jīng)double很遠，馬上triple了。

一日睡眼惺忪的清晨，正看著數(shù)據(jù)默默yy時候，線上開始告警…… MMP，用戶早上騷動的增長比想象好快呢。同事第一時間打開立體監(jiān)控瞥了一眼，結合服務的錯誤日志，很快把問題鎖定到了一個Redis實例（事實上，自從立體監(jiān)控上線以后，基本上處理流程從以前的 < 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策略，實現(xiàn)AOF文件的減肥，但是結果的冪等的。我們no-appendfsync-on-rewrite的策略是 no. 這就會導致在進行rewrite操作時，appendfsync會被阻塞。如果當前AOF文件很大，那么相應的rewrite時間會變長，appendfsync被阻塞的時間也會更長。

這不是什么新問題，很多開啟AOF的業(yè)務場景都會遇到這個問題。解決的辦法有這么幾個：

• 將no-appendfsync-on-rewrite設置為yes. 這樣可以避免與appendfsync爭用文件句柄，但是在rewrite期間的AOF有丟失的風險。

• 給當前Redis實例添加slave節(jié)點，當前節(jié)點設置為master, 然后master節(jié)點關閉AOF，slave節(jié)點開啟AOF。這樣的方式的風險是如果master掛掉，尚沒有同步到salve的數(shù)據(jù)會丟失。

我們采取了折中的方式：在master節(jié)點設置將no-appendfsync-on-rewrite設置為yes，同時添加slave節(jié)點。

理論上，問題應該解決了吧？啊蛤，的確是理論上。

修改后第一天，問題又出現(xiàn)了。驚不驚喜，意不意外？

于是，小伙伴又重新復習了一下當時出問題時候的Redis日志：

有兩個點比較可以：

1. 前幾條AOF日志告警日志發(fā)生在晚上3~5點之間，而那個時候，我們整個系統(tǒng)負載是非常低的。

2. 清晨的告警日志不是某一個Redis實例告警，而是該機器上的所有Redis實例都在告警。

感謝各位的閱讀，以上就是“分析一次非典型性Redis阻塞”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對分析一次非典型性Redis阻塞這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！