今天想和大家分享有關(guān) Redis 主從同步（也稱「復(fù)制」）的內(nèi)容。

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

那么這里有存在一個問題：從服務(wù)器如何和主服務(wù)器進行數(shù)據(jù)同步的呢？

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

文章內(nèi)容依舊比較干，建議大家靜下心來專心看，文末會給大家做個簡單總結(jié)歸納。

1. 如何進行主從同步

假如，現(xiàn)在有 2 臺 Redis 服務(wù)器，地址分別是 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 服務(wù)器就會去復(fù)制 127.0.0.1:6379 的數(shù)據(jù)。即前者是從服務(wù)器，后者為主服務(wù)器。

除了以上方式進行復(fù)制之外，還可以通過配置文件中的 slaveof 選項進行設(shè)置。

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

ok，下面我們繼續(xù)了解一下。

2. 主從同步的實現(xiàn)過程

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

• 同步：將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新成主服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)。（數(shù)據(jù)庫狀態(tài)在這篇文章開頭有提到是什么意思，不清楚的小伙伴可以先看下：《持久化》）
• 命令傳播：當(dāng)主服務(wù)器數(shù)據(jù)庫狀態(tài)被修改后，導(dǎo)致主從服務(wù)器數(shù)據(jù)庫狀態(tài)不一致，此時需要讓主從數(shù)據(jù)同步到一致的過程。

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

這里需要提前說明一下：在 Redis 2.8 版本之前，進行主從復(fù)制時一定會順序執(zhí)行上述兩個步驟，而從 2.8 開始則可能只需要執(zhí)行命令傳播即可。在下文也會解釋為什么會這樣？

2.1 同步

從服務(wù)器對主服務(wù)的同步操作，需要通過 sync 命令來實現(xiàn)，以下是 sync 命令的執(zhí)行步驟：

1. 從服務(wù)器向主服務(wù)器發(fā)送 sync 命令
2. 收到 sync 命令后，主服務(wù)器執(zhí)行 bgsave 命令，用來生成 rdb 文件，并在一個緩沖區(qū)中記錄從現(xiàn)在開始執(zhí)行的寫命令。
3. bgsave 執(zhí)行完成后，將生成的 rdb 文件發(fā)送給從服務(wù)器，用來給從服務(wù)器更新數(shù)據(jù)
4. 主服務(wù)器再將緩沖區(qū)記錄的寫命令發(fā)送給從服務(wù)器，從服務(wù)器執(zhí)行完這些寫命令后，此時的數(shù)據(jù)庫狀態(tài)便和主服務(wù)器一致了。

用圖表示就是這樣的：

2.2 命令傳播

經(jīng)過同步操作，此時主從的數(shù)據(jù)庫狀態(tài)其實已經(jīng)一致了，但這種一致的狀態(tài)的并不是一成不變的。

在完成同步之后，也許主服務(wù)器馬上就接受到了新的寫命令，執(zhí)行完該命令后，主從的數(shù)據(jù)庫狀態(tài)又不一致。

為了再次讓主從數(shù)據(jù)庫狀態(tài)一致，主服務(wù)器就需要向從服務(wù)器執(zhí)行命令傳播操作 ，即把剛才造成不一致的寫命令，發(fā)送給從服務(wù)器去執(zhí)行。從服務(wù)器執(zhí)行完成之后，主從數(shù)據(jù)庫狀態(tài)就又恢復(fù)一致了。

這里插播一個疑問：

不知道有沒有的讀者覺得，當(dāng)發(fā)生上述不一致的情況后，Redis 再執(zhí)行同步操作不就 ok 了嗎？

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

既然同步是一個非常消耗資源的操作，那 Redis 有沒有什么優(yōu)化方法呢？答案當(dāng)然是有的。

2.3 優(yōu)化版同步操作

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

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

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

• 初次復(fù)制：從服務(wù)器第一次復(fù)制當(dāng)前主服務(wù)器（PS：主服務(wù)器是有可能更換的）
• 斷線后重復(fù)制：處于命令傳播階段的主從服務(wù)器，因為網(wǎng)絡(luò)問題而中斷復(fù)制，從服務(wù)器通過自動重連，重新連接上主服務(wù)器并繼續(xù)復(fù)制。

在斷線后重復(fù)制的情況下，在 2.8 版本之前，會再次執(zhí)行同步（sync 命令）和命令傳播。

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

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

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

• 完整重同步：用于初次復(fù)制情況，執(zhí)行過程同 sync，在這不贅述了。
• 部分重同步：用于斷線后重復(fù)制情況，如果滿足一定條件，主服務(wù)器只需要將斷線期間執(zhí)行的寫命令發(fā)送給從服務(wù)器即可。

因此很明顯，當(dāng)主從同步出現(xiàn)斷線后重復(fù)制的情況，psync 的部分重同步模式可以解決 sync 的低效情況。

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

2.4 部分重同步的實現(xiàn)

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

• 主從服務(wù)器的復(fù)制偏移量
• 主服務(wù)器的復(fù)制積壓緩沖區(qū)
• 服務(wù)器的運行 id（run id）

2.4.1 復(fù)制偏移量

執(zhí)行復(fù)制的主從服務(wù)器都會分別維護各自的復(fù)制偏移量：

• 主服務(wù)器每次向從服務(wù)器傳播 n 個字節(jié)數(shù)據(jù)時，都會將自己的復(fù)制偏移量加 n。
• 從服務(wù)器接受主服務(wù)器傳來的數(shù)據(jù)時，也會將自己的復(fù)制偏移量加 n

舉個例子：

若當(dāng)前主服務(wù)器的復(fù)制偏移量為 10000，此時向從服務(wù)器傳播 30 個字節(jié)數(shù)據(jù)，結(jié)束后復(fù)制偏移量為 10030。

這時，從服務(wù)器還沒接收這 30 個字節(jié)數(shù)據(jù)就斷線了，然后重新連接上之后，該從服務(wù)器的復(fù)制偏移量依舊為 10000，說明主從數(shù)據(jù)不一致，此時會向主服務(wù)器發(fā)送 psync 命令。

那么主服務(wù)器應(yīng)該對從服務(wù)器執(zhí)行完整重同步還是部分重同步呢？如果執(zhí)行部分重同步的話，主服務(wù)器又如何知道同步哪些數(shù)據(jù)給從服務(wù)器呢？

以下答案都和復(fù)制積壓緩沖區(qū)有關(guān)

2.4.2 復(fù)制積壓緩沖區(qū)

首先，復(fù)制積壓緩沖區(qū)是一個固定長度，先進先出的隊列，默認(rèn) 1MB。

當(dāng)主服務(wù)器進行命令傳播時，不僅會將命令發(fā)送給從服務(wù)器，還會發(fā)送給這個緩沖區(qū)。

因此復(fù)制積壓緩沖區(qū)的構(gòu)造是這樣的：

當(dāng)從服務(wù)器向主服務(wù)器發(fā)送 psync 命令時，還需要將自己的復(fù)制偏移量帶上，主服務(wù)器就可以通過這個復(fù)制偏移量和復(fù)制積壓緩沖區(qū)的偏移量進行對比。

若復(fù)制積壓緩沖區(qū)存在從服務(wù)器的復(fù)制偏移量 + 1 后的數(shù)據(jù)，則進行部分重同步，否則進行完整重同步。

2.4.3 run id

運行 id 是在進行初次復(fù)制時，主服務(wù)器將會將自己的運行 id 發(fā)送給從服務(wù)器，讓其保存起來。

當(dāng)從服務(wù)器斷線重連后，從服務(wù)器會將這個運行 id 發(fā)送給剛連接上的主服務(wù)器。

若當(dāng)前服務(wù)器的運行 id 與之相同，說明從服務(wù)器斷線前復(fù)制的服務(wù)器就是當(dāng)前服務(wù)器，主服務(wù)器可以嘗試執(zhí)行部分同步；若不同則說明從服務(wù)器斷線前復(fù)制的服務(wù)器不是當(dāng)前服務(wù)器，主服務(wù)器直接執(zhí)行完整重同步。

花了很多筆墨，終于把部分重同步的實現(xiàn)寫完了，最后補充一個輔助功能

2.5 心跳檢測

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

當(dāng)完成了同步之后，主從服務(wù)器就會進入命令傳播階段，此時從服務(wù)器會以每秒 1 次的頻率，向主服務(wù)器發(fā)送命令：REPLCONF ACK replication_offset> 其中 replication_offset 是從服務(wù)器當(dāng)前的復(fù)制偏移量

發(fā)送這個命令主要有三個作用：

• 檢測主從服務(wù)器的網(wǎng)絡(luò)狀態(tài)
• 輔助實現(xiàn) min-slaves 選項
• 檢測命令丟失（若丟失，主服務(wù)器會將丟失的寫命令重新發(fā)給從服務(wù)器）

3. 總結(jié)

終于寫完了最后內(nèi)容，幾個小時又過去了，我們來總結(jié)下本文內(nèi)容吧：

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

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

• 同步：將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新成主服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)（一個消耗資源的操作）
• 命令傳播：當(dāng)主服務(wù)器數(shù)據(jù)庫狀態(tài)被修改后，導(dǎo)致主從服務(wù)器數(shù)據(jù)庫狀態(tài)不一致，此時需要讓主從數(shù)據(jù)同步到一致的過程

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

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

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

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接