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

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

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

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

文章內容依舊比較幹，一共 3k+ 字，建議大家靜下心來專心看，文末會給大家做個簡單總結歸納。

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 個步驟：同步和命令傳播

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

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

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

2.1 同步

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

1. 從服務器向主服務器發送 sync 命令

2. 收到 sync 命令後，主服務器執行 bgsave 命令，用來生成 rdb 文件，並在一個緩衝區中記錄從現在開始執行的寫命令。

3. bgsave 執行完成後，將生成的 rdb 文件發送給從服務器，用來給從服務器更新數據

4. 主服務器再將緩衝區記錄的寫命令發送給從服務器，從服務器執行完這些寫命令後，此時的數據庫狀態便和主服務器一致了。

用圖表示就是這樣的：

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> ，其中 replication_offset 是從服務器當前的複製偏移量/<replication>

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

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

3. 總結

終於到總結了，我們來總結一下，紀念下我這一個下午的時間。

• 發送 SLAVEOF 命令可以進行主從同步，比如：SLAVEOF 127.0.0.6379
• 主從同步有同步和命令傳播 2 個步驟。
• 同步：將從服務器的數據庫狀態更新成主服務器當前的數據庫狀態（一個消耗資源的操作）
• 命令傳播：當主服務器數據庫狀態被修改後，導致主從服務器數據庫狀態不一致，此時需要讓主從數據同步到一致的過程
• 主從同步分初次複製和斷線後重複製兩種情況
• 從 2.8 版本開始，在出現斷線後重複製情況時，主服務器會根據複製偏移量、複製積壓緩衝區和 run id，來確定執行完整重同步還是部分重同步
• 2.8 版本使用 psync 命令來代替 sync 命令去執行同步操作。目的是為了解決同步（sync 命令）的低效操作