redis主從複製[總結向]

---

title: Redis主從複製

date: 2020-03-29

---

歡迎前往個人博客和專欄一塊兒交流： 博客 ｜ 知乎專欄

redis主從複製是高可用方案中的一部分，那主從複製是如何進行的？又是如何實現的？怎麼支撐了redis的高可用性？在主從模式下Master和Slave節點分別作了哪些事情？

redis高可用方案是什麼？

我理解的redis高可用的特色有：

1. 高QPS，主從 => 讀寫分離
2. 高容量，集羣分片 => 高容量
3. 故障轉移，sentinel => 故障轉移
4. 故障恢復，數據持久 => 故障恢復 ～ 這裏我簡單的理解（RDB + AOF）= 故障恢復

主從複製

redis 主從複製有兩個版本：舊版（Ver2.8-），新版（Ver2.8+，增長PSYNC命令來解決舊版中的問題）

討論複製時都須要考慮兩種場景：

• 場景1：從節點剛剛上線，須要去同步主節點時，這部分能夠理解爲 全量複製。
• 場景2：從節點掉線，恢復上線後須要同步數據，使本身和主節點達到一致狀態。這部分在舊版複製裏等價於全量複製，在新版裏能夠理解爲增量複製。

固然你確定會想到若是主節點掉線，這時候會怎麼樣？這個場景固然也在redis高可用方案中，之時不是本文的重點，屬於Sentinel機制的內容了。

舊版主從複製

前文說過了，舊版主從複製只有全量複製用於應付上述兩個場景，所以下面的流程也只有一份：

1. 從服務器向主服務器發送sync命令。
2. 主服務器在收到sync命令以後，調用bgsave命令生成最新的rdb文件，將這個文件同步給從服務器，這樣從服務器載入這個rdb文件以後，狀態就會和主服務器執行bgsave命令時候的一致。
3. 主服務器將保存在命令緩衝區中的寫命令同步給從服務器，從服務器執行這些命令，這樣從服務器的狀態就跟主服務器當前狀態一致了。

若是你不知道redis中還有個緩衝區的話，建議系統的瞭解下redis中緩衝區的設計。這裏緩衝區特指命令緩衝區，後面還會講到複製緩衝區。

可是這樣的實如今 **場景2** 下的缺點很明顯：若是說從節點斷線後迅速上線，這段時間內的產生的寫命令不多，卻要**全量複製**主庫的數據，傳輸了大量重複數據。

SYNC命令產生的消耗：

1. 主節點生成RDB，須要消耗大量的CPU，內存和磁盤IO
2. 網絡傳輸大量字節數據，須要消耗主從服務器的網絡資源
3. 從節點須要從RDB文件恢復，會形成阻塞沒法接受客戶端請求

優勢就是：簡單暴力。我的看來在redis架構中不合適的用法，不表明說實際場景中也必定不合適，簡單暴力也是一個很大的優勢。

新版主從複製

新版的主從複製跟舊版的區別就在於：對場景2的優化。

場景2的缺點上文已經提到過了，那麼優化的方向就是「儘可能不使用全量複製；增長增量複製(PSYNC)的功能」。爲此還要解決下列問題：

1. 若是某個從節點斷線了，從新上線該從節點如何知道本身是否應該全量仍是增量複製呢？
2. 該從節點斷線恢復後，又怎麼知道本身缺失了哪些數據呢？
3. 主節點又如何補償該從節點在斷線期間丟失的那部分數據呢？舊版的複製除了RDB，還有從命令緩衝區中的寫命令來保持數據一致。

爲此新版中使用瞭如下概念：

運行ID - runid

每一個redis服務器都有其runid，runid由服務器在啓動時自動生成，主服務器會將本身的runid發送給從服務器，而從服務器會將主服務器的runid保存起來。從服務器redis斷線重連以後進行同步時，就是根據runid來判斷同步的進度：

1. 若是先後兩次主服務器runid一致，則認爲這一次斷線重連仍是以前複製的主服務器，主服務器能夠繼續嘗試部分同步操做。
2. 若是先後兩次主服務器runid不相同，則全同步流程。

複製偏移量 - offset

主從節點，分別會維護一個複製偏移量：

主服務器每次向從服務器同步了N字節數據以後，將修改本身的複製偏移量+N。從服務器每次從主服務器同步了N字節數據以後，將修改本身的複製偏移量+N。經過對比主從節點的偏移量很容易就能夠發現，主從節點是否處於一致狀態。

複製（積壓）緩衝區

一個固定長度（可配置）的FIFO隊列，默認大小 = 1MB；預測值 = second * write_size_per_second。當從節點從新連上主節點時候，從節點會經過PSYNC命令將本身的複製偏移量（offset）發送給主服務器，主節點會根據偏移量會判斷該執行何種同步：

1. 若是從節點offset以後的數據仍然存在複製緩衝區中，就執行部分重同步。
2. 反之，若是不存在，那麼執行徹底重同步。

由於複製緩衝區不可能無限大，所以爲了儘量多的利用部分重同步，須要針對真實場景估算出最合適的複製緩衝區大小。

至此，redis新版PSYNC經過上述概念和流程，解決了場景2下舊版複製中的資源浪費問題，流程圖和示例圖見下文。

示例圖以下，ABCD四個從節點，其中A執行部分中同步，D執行了完整重同步。

總結

水平有限，若有錯誤，歡迎勘誤指正🙏。

參考文獻

• 《redis設計與實現》
• https://zhuanlan.zhihu.com/p/...