前言：

今天想和大家分享有關 Redis 主從同步（也稱「複製」）的內容。

我們知道，當有多台 Redis 伺服器時，肯定就有一臺主伺服器和多台從伺服器。一般來說，主伺服器進行寫操作，從伺服器進行讀操作。

那麼這裡有存在一個問題：從伺服器如何和主伺服器進行數據同步的呢？

這個問題，就是通過今天的內容：主從同步來解決的。

文章內容依舊比較乾，建議大家靜下心來專心看，文末會給大家做個簡單總結歸納。

1. 如何進行主從同步

假如，現在有 2 台 Redis 伺服器，地址分別是 127.0.0.1:6379 和 127.0.0.1:12345

我們在 127.0.0.1:12345 的客戶端輸入命令：

127.0.0.1:12345> SLAVEOF 127.0.0.6379

如此 127.0.0.1:12345 伺服器就會去複製 127.0.0.1:6379 的數據。即前者是從伺服器，後者為主伺服器。

除了以上方式進行複製之外，還可以通過配置文件中的 slaveof 選項進行設置。

可能，求知欲爆棚的你會想知道，Redis 是怎麼進行主從同步的？

ok，下麵我們繼續瞭解一下。

2. 主從同步的實現過程

主從同步分為 2 個步驟：同步和命令傳播

• 同步：將從伺服器的資料庫狀態更新成主伺服器當前的資料庫狀態。（資料庫狀態在這篇文章開頭有提到是什麼意思，不清楚的小伙伴可以先看下：《持久化》）
• 命令傳播：當主伺服器資料庫狀態被修改後，導致主從伺服器資料庫狀態不一致，此時需要讓主從數據同步到一致的過程。

上面就是主從同步 2 個步驟的作用，下麵我打算稍微細說這兩個步驟的實現過程。

這裡需要提前說明一下：在 Redis 2.8 版本之前，進行主從複製時一定會順序執行上述兩個步驟，而從 2.8 開始則可能只需要執行命令傳播即可。在下文也會解釋為什麼會這樣？

2.1 同步

從伺服器對主服務的同步操作，需要通過 sync 命令來實現，以下是 sync 命令的執行步驟：

• 從伺服器向主伺服器發送 sync 命令
• 收到 sync 命令後，主伺服器執行 bgsave 命令，用來生成 rdb 文件，併在一個緩衝區中記錄從現在開始執行的寫命令。
• bgsave 執行完成後，將生成的 rdb 文件發送給從伺服器，用來給從伺服器更新數據
• 主伺服器再將緩衝區記錄的寫命令發送給從伺服器，從伺服器執行完這些寫命令後，此時的資料庫狀態便和主伺服器一致了。

用圖表示就是這樣的：

2.2 命令傳播

經過同步操作，此時主從的資料庫狀態其實已經一致了，但這種一致的狀態的並不是一成不變的。
在完成同步之後，也許主伺服器馬上就接受到了新的寫命令，執行完該命令後，主從的資料庫狀態又不一致。

為了再次讓主從資料庫狀態一致，主伺服器就需要向從伺服器執行命令傳播操作 ，即把剛纔造成不一致的寫命令，發送給從伺服器去執行。從伺服器執行完成之後，主從資料庫狀態就又恢復一致了。

這裡插播一個疑問：

不知道有沒有的讀者覺得，當發生上述不一致的情況後，Redis 再執行同步操作不就 ok 了嗎？

從效果上來說，的確是可以恢復同步，但其實沒有必要。原因是實現同步的 sync 命令是一個非常消耗資源的操作，看完下圖的說明，相信你肯定理解的。 

既然同步是一個非常消耗資源的操作，那 Redis 有沒有什麼優化方法呢？答案當然是有的。

2.3 優化版同步操作

還記得上面說的內容嗎 —— 2.8 版本開始，進行主從同步可能只需要執行命令傳播即可。這個也是因為 sync 比較耗資源，從而採取的優化。

那什麼時候可以這麼做呢？我們先看下前提條件：

主從同步實際分 2 種情況：

• 初次複製：從伺服器第一次複製當前主伺服器（PS：主伺服器是有可能更換的）
• 斷線後重覆制：處於命令傳播階段的主從伺服器，因為網路問題而中斷複製，從伺服器通過自動重連，重新連接上主伺服器並繼續複製。

在斷線後重覆制的情況下，在 2.8 版本之前，會再次執行同步（sync 命令）和命令傳播。

如果說，在斷線期間，主伺服器（已有上萬鍵值對）只執行了幾個寫命令，為了讓從伺服器彌補這幾個命令，卻要重新執行 sync 來生成新的 rdb 文件，這也是非常低效的。

為瞭解決這個問題，2.8 開始就使用 psync 命令來代替 sync 命令去執行同步操作。

psync 具有完整重同步和部分重同步兩種模式：

• 完整重同步：用於初次複製情況，執行過程同 sync，在這不贅述了。
• 部分重同步：用於斷線後重覆制情況，如果滿足一定條件，主伺服器只需要將斷線期間執行的寫命令發送給從伺服器即可。

因此很明顯，當主從同步出現斷線後重覆制的情況，psync 的部分重同步模式可以解決 sync 的低效情況。

上面的介紹中，出現了「滿足一定條件」，那又是鬼什麼條件呢？—— 其實就是一個偏移量的比較，具體可以繼續往下看。

2.4 部分重同步的實現

部分重同步功能由以下 3 部分組成：

• 主從伺服器的複製偏移量
• 主伺服器的複製積壓緩衝區
• 伺服器的運行 id（run id）

2.4.1 複製偏移量

執行複製的主從伺服器都會分別維護各自的複製偏移量：

• 主伺服器每次向從伺服器傳播 n 個位元組數據時，都會將自己的複製偏移量加 n。
• 從伺服器接受主伺服器傳來的數據時，也會將自己的複製偏移量加 n

舉個例子：

若當前主伺服器的複製偏移量為 10000，此時向從伺服器傳播 30 個位元組數據，結束後複製偏移量為 10030。

這時，從伺服器還沒接收這 30 個位元組數據就斷線了，然後重新連接上之後，該從伺服器的複製偏移量依舊為 10000，說明主從數據不一致，此時會向主伺服器發送 psync 命令。

那麼主伺服器應該對從伺服器執行完整重同步還是部分重同步呢？如果執行部分重同步的話，主伺服器又如何知道同步哪些數據給從伺服器呢？

以下答案都和複製積壓緩衝區有關

2.4.2 複製積壓緩衝區

首先，複製積壓緩衝區是一個固定長度，先進先出的隊列，預設 1MB。

當主伺服器進行命令傳播時，不僅會將命令發送給從伺服器，還會發送給這個緩衝區。

因此複製積壓緩衝區的構造是這樣的：

當從伺服器向主伺服器發送 psync 命令時，還需要將自己的複製偏移量帶上，主伺服器就可以通過這個複製偏移量和複製積壓緩衝區的偏移量進行對比。

若複製積壓緩衝區存在從伺服器的複製偏移量 + 1 後的數據，則進行部分重同步，否則進行完整重同步。

2.4.3 run id

運行 id 是在進行初次複製時，主伺服器將會將自己的運行 id 發送給從伺服器，讓其保存起來。

當從伺服器斷線重連後，從伺服器會將這個運行 id 發送給剛連接上的主伺服器。

若當前伺服器的運行 id 與之相同，說明從伺服器斷線前複製的伺服器就是當前伺服器，主伺服器可以嘗試執行部分同步；若不同則說明從伺服器斷線前複製的伺服器不是當前伺服器，主伺服器直接執行完整重同步。

花了很多筆墨，終於把部分重同步的實現寫完了，最後補充一個輔助功能

2.5 心跳檢測

剛纔提到，主從同步有同步和命令傳播 2 個步驟。

當完成了同步之後，主從伺服器就會進入命令傳播階段，此時從伺服器會以每秒 1 次的頻率，向主伺服器發送命令：REPLCONF ACK <replication_offset> 其中 replication_offset 是從伺服器當前的複製偏移量

發送這個命令主要有三個作用：

• 檢測主從伺服器的網路狀態
• 輔助實現 min-slaves 選項
• 檢測命令丟失（若丟失，主伺服器會將丟失的寫命令重新發給從伺服器）

3. 總結

發送 SLAVEOF 命令可以進行主從同步，比如：SLAVEOF 127.0.0.6379

主從同步有同步和命令傳播 2 個步驟。

• 同步：將從伺服器的資料庫狀態更新成主伺服器當前的資料庫狀態（一個消耗資源的操作）
• 命令傳播：當主伺服器資料庫狀態被修改後，導致主從伺服器資料庫狀態不一致，此時需要讓主從數據同步到一致的過程

主從同步分初次複製和斷線後重覆制兩種情況

• 從 2.8 版本開始，在出現斷線後重覆制情況時，主伺服器會根據複製偏移量、複製積壓緩衝區和 run id，來確定執行完整重同步還是部分重同步

2.8 版本使用 psync 命令來代替 sync 命令去執行同步操作。目的是為瞭解決同步（sync 命令）的低效操作。

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值。