一篇文章讓你明白Redis主從同步

今天想和大家分享有關 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 命令的執行步驟：

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_offset> 其中 replication_offset 是從服務器當前的復制偏移量

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

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

3. 總結

終于寫完了最后內容，幾個小時又過去了，我們來總結下本文內容吧：

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

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

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

主從同步分初次復制和斷線后重復制兩種情況

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

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

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。如果你想了解更多相關內容請查看下面相關鏈接