介紹 Redis 的復(fù)制

Redis 的復(fù)制功能分為同步（sync）和命令傳播（command propagate）這兩個(gè)操作

• 同步操作用于，將從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)更新至主服務(wù)器當(dāng)前所處的數(shù)據(jù)庫(kù)狀態(tài)；
• 命令傳播操作用于，在主服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)被修改，導(dǎo)致主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)出現(xiàn)不一致時(shí)，讓主從服務(wù)器的數(shù)據(jù)庫(kù)重新回到一致狀態(tài)。

如果主從服務(wù)器雙方的數(shù)據(jù)庫(kù)保存相同的數(shù)據(jù)，我們稱主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)一致

當(dāng)從服務(wù)器第一次連接主服務(wù)器時(shí)，Redis 使用全量復(fù)制進(jìn)行數(shù)據(jù)同步。

當(dāng)從服務(wù)器在斷線后重新連接主服務(wù)器時(shí)，Redis 使用增量復(fù)制進(jìn)行數(shù)據(jù)同步。

完整重同步

全量復(fù)制，也被稱為完整重同步。

當(dāng)客戶端向從服務(wù)器發(fā)送 slaveof 命令，要求從服務(wù)器復(fù)制主服務(wù)器時(shí)，從服務(wù)器首先需要執(zhí)行同步操作，將從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)更新至主服務(wù)器當(dāng)前所處的數(shù)據(jù)庫(kù)狀態(tài)。

從服務(wù)器對(duì)主服務(wù)器的完整重同步操作，需要通過向主服務(wù)器發(fā)送 psync 命令來(lái)完成。psync 的命令為：psync ? -1

psync 命令在完整重同步模式下的的執(zhí)行步驟：讓主服務(wù)器創(chuàng)建并發(fā)送 RDB 文件，以及主服務(wù)器向從服務(wù)器發(fā)送保存在緩沖區(qū)里面的寫命令來(lái)進(jìn)行同步。

• 從服務(wù)器向主服務(wù)器發(fā)送 psync 命令。
• 主服務(wù)器收到 psync 命令后，主服務(wù)器執(zhí)行 bgsave 命令，在后臺(tái)生成一個(gè) RDB 文件，并使用一個(gè)緩沖區(qū)（replication buffer）記錄從現(xiàn)在開始執(zhí)行的所有寫命令。
• 主服務(wù)器給從服務(wù)器同步數(shù)據(jù)：當(dāng)主服務(wù)器的 bgsave 命令執(zhí)行完畢時(shí)，主服務(wù)器會(huì)將 bgsave 命令生成的 RDB 文件發(fā)送給從服務(wù)器，從服務(wù)器接收并載入這個(gè) RDB 文件，將自己的數(shù)據(jù)庫(kù)狀態(tài)更新至主服務(wù)器執(zhí)行 bgsave 命令時(shí)的數(shù)據(jù)庫(kù)狀態(tài)。
• 主服務(wù)器給從服務(wù)器發(fā)送緩沖區(qū)里面的所有寫命令：主服務(wù)器將記錄在緩沖區(qū)里面的所有寫命令發(fā)送給從服務(wù)器， 從服務(wù)器執(zhí)行這些寫命令，將自己的數(shù)據(jù)庫(kù)狀態(tài)更新至主服務(wù)器數(shù)據(jù)庫(kù)當(dāng)前所處的狀態(tài)。

需要注意的是：

從庫(kù)在開始和主庫(kù)進(jìn)行數(shù)據(jù)復(fù)制前，可能保存了其他數(shù)據(jù)。為了避免之前數(shù)據(jù)的影響，從庫(kù)在收到主庫(kù)發(fā)送的 RDB 文件后，會(huì)先把自己當(dāng)前的數(shù)據(jù)庫(kù)清空。

介紹 偏移量 & 積壓緩沖區(qū) & 運(yùn)行ID

部分重同步功能通過以下三個(gè)部分來(lái)實(shí)現(xiàn)：

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

復(fù)制偏移量

主服務(wù)器和從服務(wù)器會(huì)分別維護(hù)一個(gè)復(fù)制偏移量：

• 主服務(wù)器每次向從服務(wù)器傳播 N 個(gè)字節(jié)的數(shù)據(jù)時(shí)，就將自己的復(fù)制偏移量的值加上 N。
• 從服務(wù)器每次收到主服務(wù)器傳播來(lái)的 N 個(gè)字節(jié)的數(shù)據(jù)時(shí)，就將自己的復(fù)制偏移量的值加上 N。

通過對(duì)比主從服務(wù)器的復(fù)制偏移量，程序可以很容易地知道主從服務(wù)器是否處于一致狀態(tài)：

• 如果主從服務(wù)器兩者的偏移量總是相同，那么說(shuō)明主從服務(wù)器處于一致狀態(tài)。
• 如果主從服務(wù)器兩者的偏移量并不相同，那么說(shuō)明主從服務(wù)器并未處于一致狀態(tài)。

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

復(fù)制積壓緩沖區(qū)（repl_backlog_buffer）是由主服務(wù)器維護(hù)的一個(gè)固定長(zhǎng)度的先進(jìn)先出（FIFO）隊(duì)列。

固定指的是，當(dāng)入隊(duì)元素的數(shù)量大于隊(duì)列長(zhǎng)度時(shí)，最先入隊(duì)的元素會(huì)被彈出，而新元素會(huì)被放入隊(duì)列?；蛘呃斫鈴?fù)制積壓緩沖區(qū)為一個(gè)環(huán)形緩沖區(qū)。

當(dāng)主服務(wù)器進(jìn)行命令傳播時(shí)，它不僅會(huì)將寫命令發(fā)送給所有從服務(wù)器，還會(huì)將寫命令入隊(duì)到復(fù)制積壓緩沖區(qū)里面。

因此，主服務(wù)器的復(fù)制積壓緩沖區(qū)里面會(huì)保存著一部分最近傳播的寫命令，并且復(fù)制積壓緩沖區(qū)會(huì)為隊(duì)列中的每個(gè)字節(jié)記錄相應(yīng)的復(fù)制偏移量。

當(dāng)從服務(wù)器在斷線后重新連接主服務(wù)器時(shí)，從服務(wù)器會(huì)通過 psync 命令將自己的復(fù)制偏移量 offset 發(fā)送給主服務(wù)器，主服務(wù)器會(huì)根據(jù)這個(gè)復(fù)制偏移量來(lái)決定對(duì)從服務(wù)器執(zhí)行完整重同步還是部分重同步操作：

• 如果 offset 偏移量之后的數(shù)據(jù)（也即是偏移量 offset+1 開始的數(shù)據(jù)）仍然存在于復(fù)制積壓緩沖區(qū)里面，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行部分重同步操作。
• 如果 offset 偏移量之后的數(shù)據(jù)已經(jīng)不存在于復(fù)制積壓緩沖區(qū)，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行完整重同步操作。

復(fù)制積壓緩沖區(qū)的大小

Redis 為復(fù)制積壓緩沖區(qū)設(shè)置的默認(rèn)大小為 1MB，如果主服務(wù)器需要執(zhí)行大量的寫命令，又或者主從服務(wù)器斷線后重連接所需的時(shí)間比較長(zhǎng)，那么這個(gè)大小也許并不合適。我們可以通過 repl-backlog-size 選項(xiàng)修改復(fù)制積壓緩沖區(qū)的大小。

如果復(fù)制積壓緩沖區(qū)的大小設(shè)置得不恰當(dāng)，那么 psync 命令的部分重同步復(fù)制就不能正常發(fā)揮作用。因此，正確估算和設(shè)置復(fù)制積壓緩沖區(qū)的大小非常重要。

為了保證主從服務(wù)器斷線并重連接后可以使用部分重同步功能，我們需要保證復(fù)制積壓緩沖區(qū)的大小足夠大。復(fù)制積壓緩沖區(qū)的最小大小可以根據(jù)公式 second * write_size_per_second 來(lái)估算：

• second 是從服務(wù)器斷線后重新連接上主服務(wù)器所需的平均時(shí)間（以秒計(jì)算）。
• write_size_per_second 是主服務(wù)器平均每秒產(chǎn)生的寫命令數(shù)據(jù)量（協(xié)議格式的寫命令的長(zhǎng)度總和）。

例如，如果主服務(wù)器平均每秒產(chǎn)生1 MB的寫數(shù)據(jù)，而從服務(wù)器斷線之后平均要 5 秒才能重新連接上主服務(wù)器，那么復(fù)制積壓緩沖區(qū)的大小就不能低于 5 MB。

為了安全起見，可以將復(fù)制積壓緩沖區(qū)的大小設(shè)為： 2 * second * write_size_per_second，這樣可以保證絕大部分?jǐn)嗑€情況都能用部分重同步來(lái)處理。

服務(wù)器運(yùn)行 ID

每個(gè) Redis 服務(wù)器，不論主服務(wù)器還是從服務(wù)，都會(huì)有自己的運(yùn)行 ID。運(yùn)行 ID 在服務(wù)器啟動(dòng)時(shí)自動(dòng)生成，由 40 個(gè)隨機(jī)的十六進(jìn)制字符組成，例如：53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3。

當(dāng)從服務(wù)器對(duì)主服務(wù)器進(jìn)行初次復(fù)制時(shí)，主服務(wù)器會(huì)將自己的運(yùn)行 ID 發(fā)送給從服務(wù)器，而從服務(wù)器會(huì)將主服務(wù)器的這個(gè)運(yùn)行 ID 保存起來(lái)。 當(dāng)從服務(wù)器斷線并重新連上一個(gè)主服務(wù)器時(shí)，從服務(wù)器將向當(dāng)前連接的主服務(wù)器發(fā)送之前保存的主服務(wù)器的運(yùn)行 ID：

• 如果從服務(wù)器保存的主服務(wù)器的運(yùn)行 ID 和當(dāng)前連接的主服務(wù)器的運(yùn)行 ID 相同，那么說(shuō)明從服務(wù)器斷線之前復(fù)制的就是當(dāng)前連接的這個(gè)主服務(wù)器， 主服務(wù)器可以繼續(xù)嘗試執(zhí)行部分重同步操作。
• 如果從服務(wù)器保存的主服務(wù)器的運(yùn)行 ID 和當(dāng)前連接的主服務(wù)器的運(yùn)行 ID 并不相同，那么說(shuō)明從服務(wù)器斷線之前復(fù)制的主服務(wù)器并不是當(dāng)前連接的這個(gè)主服務(wù)器，主服務(wù)器將對(duì)從服務(wù)器執(zhí)行完整重同步操作。

部分重同步

增量復(fù)制，也被稱為部分重同步。

在 Redis 中，從庫(kù)對(duì)主庫(kù)的復(fù)制可以分為以下兩種情況：

• 初次復(fù)制：從庫(kù)以前沒有復(fù)制過任何主庫(kù)，或者從庫(kù)當(dāng)前要復(fù)制的主服務(wù)器和上一次復(fù)制的主服務(wù)器不同。
• 網(wǎng)絡(luò)斷線重連后復(fù)制：處于命令傳播階段的主從庫(kù)因?yàn)榫W(wǎng)絡(luò)原因而中斷了復(fù)制，但從庫(kù)通過自動(dòng)重連接重新連上了主庫(kù)，并繼續(xù)復(fù)制主服。

在 Redis 2.8 之前，如果主從庫(kù)在命令傳播時(shí)出現(xiàn)了網(wǎng)絡(luò)中斷，那么在斷線重連后，從庫(kù)會(huì)和主庫(kù)重新進(jìn)行一次全量復(fù)制，開銷非常大。

從 2.8 版本開始，Redis 引入了部分重同步功能。部分重同步指的是，從服務(wù)器只同步主服務(wù)器的部分?jǐn)?shù)據(jù)。當(dāng)從服務(wù)器在斷線后重新連接主服務(wù)器時(shí)，如果條件允許，主服務(wù)器可以將主從服務(wù)器連接斷開期間執(zhí)行的寫命令發(fā)送給從服務(wù)器，從服務(wù)器只要接收并執(zhí)行這些寫命令，就可以將數(shù)據(jù)庫(kù)更新至主服務(wù)器當(dāng)前所處的狀態(tài)。

執(zhí)行部分重同步是有前提條件的。

• offset 偏移量
• 運(yùn)行 ID

當(dāng)從服務(wù)器對(duì)主服務(wù)器進(jìn)行初次復(fù)制時(shí)，主服務(wù)器會(huì)將自己的運(yùn)行 ID 發(fā)送給從服務(wù)器，而從服務(wù)器會(huì)將主服務(wù)器的這個(gè)運(yùn)行 ID 保存起來(lái)。 當(dāng)從服務(wù)器斷線并重新連上一個(gè)主服務(wù)器時(shí)，從服務(wù)器會(huì)通過 psync 命令將自己的復(fù)制偏移量 offset 和 之前保存的主服務(wù)器的運(yùn)行 ID 發(fā)送給主服務(wù)器。

主服務(wù)器會(huì)根據(jù)這個(gè)復(fù)制偏移量 和 運(yùn)行ID 來(lái)決定對(duì)從服務(wù)器執(zhí)行完整重同步還是部分重同步操作：

• 如果從服務(wù)器保存的主服務(wù)器的運(yùn)行 ID 和當(dāng)前連接的主服務(wù)器的運(yùn)行 ID 相同，那么說(shuō)明從服務(wù)器斷線之前復(fù)制的就是當(dāng)前連接的這個(gè)主服務(wù)器， 主服務(wù)器可以繼續(xù)嘗試執(zhí)行部分重同步操作。
• 如果從服務(wù)器保存的主服務(wù)器的運(yùn)行 ID 和當(dāng)前連接的主服務(wù)器的運(yùn)行 ID 并不相同，那么說(shuō)明從服務(wù)器斷線之前復(fù)制的主服務(wù)器并不是當(dāng)前連接的這個(gè)主服務(wù)器，主服務(wù)器將對(duì)從服務(wù)器執(zhí)行完整重同步操作。
• 如果 offset 偏移量之后的數(shù)據(jù)（也即是偏移量 offset+1 開始的數(shù)據(jù)）仍然存在于復(fù)制積壓緩沖區(qū)里面，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行部分重同步操作。
• 如果 offset 偏移量之后的數(shù)據(jù)已經(jīng)不存在于復(fù)制積壓緩沖區(qū)，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行完整重同步操作。

從服務(wù)器對(duì)主服務(wù)器的部分重同步操作，需要通過向主服務(wù)器發(fā)送 psync 命令來(lái)完成。psync 命令為：psync < runID > < offset >

psync 命令

從服務(wù)器對(duì)主服務(wù)器的同步操作，需要通過向主服務(wù)器發(fā)送 psync 命令來(lái)完成。

psync 命令具有完整重同步（full resynchronization）和部分重同步 （partial resynchronization）兩種模式：

• 完整重同步用于，處理初次復(fù)制情況；
• 部分重同步用于，處理斷線后重復(fù)制情況：當(dāng)從服務(wù)器在斷線后重新連接主服務(wù)器時(shí)，如果條件允許，主服務(wù)器可以將主從服務(wù)器連 接斷開期間執(zhí)行的寫命令發(fā)送給從服務(wù)器，從服務(wù)器只要接收并執(zhí)行這 些寫命令，就可以將數(shù)據(jù)庫(kù)更新至主服務(wù)器當(dāng)前所處的狀態(tài)。

psync 命令的調(diào)用方法有兩種：

• 如果從服務(wù)器以前沒有復(fù)制過任何主服務(wù)器，或者之前執(zhí)行過 slaveof no one 命令，那么從服務(wù)器在開始一次新的復(fù)制時(shí)將向主服務(wù)器發(fā)送 psync ? -1 命令，主動(dòng)請(qǐng)求主服務(wù)器進(jìn)行完整重同步。
• 如果從服務(wù)器已經(jīng)復(fù)制過某個(gè)主服務(wù)器，那么從服務(wù)器在開始一次新的復(fù)制時(shí)將向主服務(wù)器發(fā)送 psync 命令：其中 runid 是上一次復(fù)制的主服務(wù)器的運(yùn)行 ID，而 offset 則是從服務(wù)器當(dāng)前的復(fù)制偏移量，接收到這個(gè)命令的主服務(wù)器會(huì)通過這兩個(gè)參數(shù)來(lái)判斷應(yīng)該對(duì)從服務(wù)器執(zhí)行哪種同步操作。

根據(jù)情況，接收到 psync 命令的主服務(wù)器會(huì)向從服務(wù)器返回以下三種回復(fù)的其中一種：

• 如果主服務(wù)器返回 +fullresync 回復(fù)，那么表示主服務(wù)器將與從服務(wù)器執(zhí)行完整重同步操作：其中 runid 是這個(gè)主服務(wù)器的運(yùn)行 ID，從服務(wù)器會(huì)將這個(gè) ID 保存起來(lái)，在下一次發(fā)送 psync 命令時(shí)使用；而 offset 則是主服務(wù)器當(dāng)前的復(fù)制偏移量，從服務(wù)器會(huì)將這個(gè)值作為自己的初始化偏移量。
• 如果主服務(wù)器返回 +continue 回復(fù)，那么表示主服務(wù)器將與從服務(wù)器執(zhí)行部分重同步操作，從服務(wù)器只要等著主服務(wù)器將自己缺少的那部分?jǐn)?shù)據(jù)發(fā)送過來(lái)就可以了。
• 如果主服務(wù)器返回 -err 回復(fù)，那么表示主服務(wù)器的版本低于 Redis2.8，它識(shí)別不了 psync 命令，從服務(wù)器將向主服務(wù)器發(fā)送 sync 命令，并與主服務(wù)器執(zhí)行完整同步操作。

命令傳播

主服務(wù)器通過向從服務(wù)器傳播命令來(lái)更新從服務(wù)器的狀態(tài)，保持主從服務(wù)器一致。

當(dāng)完成了同步之后， 主從服務(wù)器就會(huì)進(jìn)入命令傳播階段， 這時(shí)主服務(wù)器只要一直將自己執(zhí)行的寫命令發(fā)送給從服務(wù)器， 而從服務(wù)器只要一直接收并執(zhí)行主服務(wù)器發(fā)來(lái)的寫命令， 就可以保證主從服務(wù)器一直保持一致了。

主服務(wù)器進(jìn)行命令傳播時(shí)，它不僅會(huì)將寫命令發(fā)送給所有從服務(wù)器，還會(huì)將寫命令入隊(duì)到復(fù)制積壓緩沖區(qū)里面。

心跳檢測(cè)

從服務(wù)器通過向主服務(wù)器發(fā)送命令來(lái)進(jìn)行心跳檢測(cè)，以及命令丟失檢測(cè)。

在命令傳播階段，從服務(wù)器默認(rèn)會(huì)以每秒一次的頻率，向主服務(wù)器發(fā)送命令：replconf ack <replication_offset>。其中 replication_offset 是從服務(wù)器當(dāng)前的復(fù)制偏移量。

發(fā)送 replconf ack 命令對(duì)于主從服務(wù)器有三個(gè)作用：

• 檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)連接狀態(tài)。
• 輔助實(shí)現(xiàn) min-slaves 選項(xiàng)。
• 檢測(cè)命令丟失。

檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)連接狀態(tài)。

主從服務(wù)器可以通過發(fā)送和接收 replconf ack 命令來(lái)檢查兩者之間的網(wǎng)絡(luò)連接是否正常：如果主服務(wù)器超過一秒鐘沒有收到從服務(wù)器發(fā)來(lái)的 replconf ack 命令，那么主服務(wù)器就知道主從服務(wù)器之間的連接出現(xiàn)問題了。

通過向主服務(wù)器發(fā)送 info replication 命令，在列出的從服務(wù)器列表的 lag 一欄中，我們可以看到相應(yīng)從服務(wù)器最后一次向主服務(wù)器發(fā)送 replconf ack 命令距離現(xiàn)在過了多少秒。在一般情況下，lag 的值應(yīng)該在 0 秒或者 1 秒之間跳動(dòng)，如果超過 1 秒的話，那么說(shuō)明主從服務(wù)器之間的連接出現(xiàn)了故障。

輔助實(shí)現(xiàn) min-slaves 選項(xiàng)。

Redis 的 min-slaves-to-write 和 min-slaves-max-lag 兩個(gè)選項(xiàng)可以防止主服務(wù)器在不安全的情況下執(zhí)行寫命令。

舉個(gè)例子，如果我們向主服務(wù)器提供以下設(shè)置：

• min-slaves-to-write 3
• min-slaves-max-lag 10

那么在從服務(wù)器的數(shù)量少于 3 個(gè)，或者 3 個(gè)從服務(wù)器的延遲（lag）值都 ≥ 10 秒時(shí)，主服務(wù)器將拒絕執(zhí)行寫命令，這里的延遲值就是上面提到的 info replication 命令的 lag 值。

檢測(cè)命令丟失。

如果因?yàn)榫W(wǎng)絡(luò)故障，主服務(wù)器傳播給從服務(wù)器的寫命令在半路丟失，那么當(dāng)從服務(wù)器向主服務(wù)器發(fā)送 replconf ack 命令時(shí)，主服務(wù)器將發(fā)覺從服務(wù)器當(dāng)前的復(fù)制偏移量少于自己的復(fù)制偏移量，然后主服務(wù)器就會(huì)根據(jù)從服務(wù)器提交的復(fù)制偏移量，在復(fù)制積壓緩沖區(qū)里面找到從服務(wù)器缺少的數(shù)據(jù)，并將這些數(shù)據(jù)重新發(fā)送給從服務(wù)器。

參考資料

《Redis設(shè)計(jì)與實(shí)現(xiàn)》

到此這篇關(guān)于Redis的數(shù)據(jù)復(fù)制的文章就介紹到這了,更多相關(guān)Redis的數(shù)據(jù)復(fù)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論