一、主從複製簡介

Redis 主從架構下，使用預設的非同步複製模式來同步資料，其特點是低延遲和高效能。當 Redis master 下有多個 slave 節點，且 slave 節點無法進行部分重同步時， slave 會請求進行全量資料同步，此時 master 需要建立 RDB 快照快照傳送給 slave ，從節點收到 RDB 快照開始解析與載入。

二、主從複製風暴

在複製重建的過程中，slave 節點載入 RDB 還未完成，卻因為一些原因導致失敗了，slave 節點此時又會再次發起全量同步 RDB 的請求，迴圈往復。當多個 slave 節點同時迴圈請求時，導致了複製風暴的出現。

三、問題現象

3.1 CPU：

master 節點會非同步生成 RDB 快照，資料量非常大時 fork 子程式非常耗時，同時 CPU 會飆升，且會影響業務正常響應。

3.2 磁碟：

從 Redis 2.8.18 版本開始，支援無磁碟複製，非同步生成的RDB快照將在子程式中直接傳送 RDB 快照至 slave 節點，多個 slave 節點共享同一份快照。所以磁碟 IO 並不會出現異常。

3.3 記憶體與網路：

由於 RDB 是在記憶體中建立與傳送，當複製風暴發起時，master 節點建立RDB快照後會向多個 slave 節點進行傳送，可能使 master 節點記憶體與網路頻寬消耗嚴重，造成主節點的延遲變大，極端情況會發生主從節點之間連線斷開，導致複製失敗。slave 節點在失敗重連後再次發起新一輪的全量複製請求，陷入惡性迴圈。

四、出現的場景

單
master 節點（主機上只
有一臺redis例項）當機器發生故障導致網路中斷或重啟恢復時。
多 m
aster 節點在同一臺機
器上，當機器發生故障導致網路中斷或重啟恢復時。
大量 slave 節點同時重啟恢復。
複製緩衝區過小，緩衝區的上限是由 client-output-buffer-limit 配置項決定的，當 slave 還在恢復 RDB 快照時，master 節點持續產生資料，緩衝區如果被寫滿了，會導致 slave 節點連線斷開，再次發起重建複製請求。發起全量複製->複製緩衝區溢位->連線中斷->重連->發起全量複製->複製緩衝區溢位->連線中斷->重連...
網路長時間中斷導致的連線異常：跨機房、跨雲、DNS 解析異常等導致的主從節點之間連線丟失。主從節點判斷超時（觸發了repl-timeout），且丟失的資料過多，超過了複製積壓緩衝區所能儲存的範圍。
資料量過大，生成 RDB 快照的 fork 子程式操作耗時過長，導致 slave 節點長時間收不到資料而觸發超時，此時 slave 節點會重連 master 節點，再次請求進行全量複製，再次超時，再次重連。

五、解決方案

5.1 降低儲存上限

單個Redis 例項的儲存資料的上限不要過大，過高的情況下會影響 RDB 落盤速度、向 slave 節點傳送速度、slave 節點恢復速度。

5.2 複製緩衝區調整

master 節點 client-output-buffer-limit 配置項閾值增大（或調整為不限制），repl_timeout 配置項閾值增大。使 slave 節點有足夠的時候恢復RDB快照並且不會被動斷開連線。

5.3 部署方式調整

單個主機節點內儘量不再部署多個 master 節點，防止主機因為意外情況導致所有 slave 節點的全量同步請求傳送至同一主機內。

5.4 架構調整

減少 slave 節點個數。或調整 slave 架構層級，在 Redis 4.0 版本之後，sub-slave 訂閱 slave 時將會收到與 master 一樣的複製資料流。

本文關鍵字：#Redis主從複製# #Redis複製風暴#

故障分析 | Redis 主從複製風暴