一篇文章讓你明白R(shí)edis主從同步

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

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

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

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

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

1. 如何進(jìn)行主從同步

假如，現(xiàn)在有 2 臺(tái) Redis 服務(wù)器，地址分別是 127.0.0.1:6379 和 127.0.0.1:12345

我們?cè)?127.0.0.1:12345 的客戶端輸入命令：

127.0.0.1:12345> SLAVEOF 127.0.0.6379

如此 127.0.0.1:12345 服務(wù)器就會(huì)去復(fù)制 127.0.0.1:6379 的數(shù)據(jù)。即前者是從服務(wù)器，后者為主服務(wù)器。

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

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

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

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

主從同步分為 2 個(gè)步驟：同步和命令傳播

• 同步：將從服務(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í)需要讓主從數(shù)據(jù)同步到一致的過程。

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

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

2.1 同步

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

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

用圖表示就是這樣的：

2.2 命令傳播

經(jīng)過同步操作，此時(shí)主從的數(shù)據(jù)庫狀態(tài)其實(shí)已經(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ù)一致了。

這里插播一個(gè)疑問：

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

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

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

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

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

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

主從同步實(shí)際分 2 種情況：

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

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

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

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

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

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

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

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

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

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

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

2.4.1 復(fù)制偏移量

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

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

舉個(gè)例子：

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

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

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

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

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

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

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

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

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

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

2.4.3 run id

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

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

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

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

2.5 心跳檢測(cè)

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

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

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

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

3. 總結(jié)

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

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

主從同步有同步和命令傳播 2 個(gè)步驟。

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

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

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

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

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