面試官常問：Redis主從是如何同步的省店？

程序員圣經(jīng)

3天前

作者：七淅

來源：公眾號不只Java

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

我們知道潘拱，當(dāng)有多臺 Redis 服務(wù)器時，肯定就有一臺主服務(wù)器和多臺從服務(wù)器寡喝。一般來說圆仔，主服務(wù)器進(jìn)行寫操作，從服務(wù)器進(jìn)行讀操作甩十。

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

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

文章內(nèi)容依舊比較干鸭轮，一共 3k+ 字，建議大家靜下心來專心看橄霉，文末會給大家做個簡單總結(jié)歸納窃爷。

一、如何進(jìn)行主從同步

假如姓蜂，現(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ù)器逮京。

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

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

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

二挟裂、主從同步的實現(xiàn)過程

主從同步分為 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ù)同步到一致的過程栗竖。

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

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

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、命令傳播

經(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)然是有的。

3嬉挡、優(yōu)化版同步操作

還記得上面說的內(nèi)容嗎 —— 2.8 版本開始钝鸽，進(jìn)行主從同步可能只需要執(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ù)往下看琅攘。

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

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

主從服務(wù)器的復(fù)制偏移量

主服務(wù)器的復(fù)制積壓緩沖區(qū)

服務(wù)器的運行 id（run id）

1） 復(fù)制偏移量

執(zhí)行復(fù)制的主從服務(wù)器都會分別維護(hù)各自的復(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） 復(fù)制積壓緩沖區(qū)

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

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

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

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

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

3） run id

運行 id 是在進(jìn)行初次復(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)寫完了，最后補充一個輔助功能

5茸时、心跳檢測

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

當(dāng)完成了同步之后可都，主從服務(wù)器就會進(jìn)入命令傳播階段缓待，此時從服務(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ù)器）

三、總結(jié)

終于到總結(jié)了签杈，我們來總結(jié)一下瘫镇，紀(jì)念下我這一個下午的時間。

發(fā)送 SLAVEOF 命令可以進(jìn)行主從同步芹壕，比如：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 命令）的低效操作

1645閱讀

搜索

60道redis面試題

redis深度面試題

redis一致性hash算法

mongodb和redis哪個好

redis分布式鎖

mongodb+redis面試題