Redis 復(fù)制過程詳解

丹楓無跡 2022-09-12 發(fā)布于北京

展開全文

Redis 的復(fù)制功能分為同步( sync )和命令傳播( command propagate )兩個步驟：

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

同步

Redis 使用 psync 命令完成主從數(shù)據(jù)同步，同步過程分為：全量復(fù)制和部分復(fù)制。

全量復(fù)制：一般用于初次復(fù)制場景，它會把主節(jié)點全部數(shù)據(jù)一次性發(fā)送給從節(jié)點發(fā)送給從節(jié)點，當(dāng)數(shù)據(jù)量較大時，會對主從節(jié)點和網(wǎng)絡(luò)造成很大的開銷。

部分復(fù)制：用于處理在主從復(fù)制中因網(wǎng)絡(luò)閃斷等原因造成的網(wǎng)絡(luò)丟失場景，當(dāng)從節(jié)點再次連接上主節(jié)點后，如果條件允許，主節(jié)點會補發(fā)丟失數(shù)據(jù)給從節(jié)點。因為補發(fā)的數(shù)據(jù)遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù)，可以有效避免全量復(fù)制的過高開銷。

psync 命令運行需要以下組件支持：

主從節(jié)點各自復(fù)制偏移量
主節(jié)點復(fù)制積壓緩沖區(qū)
主節(jié)點運行 id

參與復(fù)制的從節(jié)點都會維護(hù)自身復(fù)制偏移量。主節(jié)點在處理完寫命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計在 info replication 中的 masterreploffset 指標(biāo)中。從節(jié)點在接收到主節(jié)點發(fā)送的命令后，也會累加記錄自身的偏移量，并且會每秒鐘上報自身的復(fù)制偏移量給主節(jié)點。通過對比主從節(jié)點的復(fù)制偏移量，可以判斷主從節(jié)點數(shù)據(jù)是否一致。

復(fù)制積壓緩沖區(qū)是保存在主節(jié)點的一個固定長度的隊列，默認(rèn)大小為 1MB，當(dāng)主節(jié)點有連接的從節(jié)點時被創(chuàng)建。主節(jié)點響應(yīng)寫命令時，不但會把命令發(fā)送給從節(jié)點，還會寫入復(fù)制積壓緩沖區(qū)中。

復(fù)制積壓緩沖區(qū)大小有限，只能保存最近的復(fù)制數(shù)據(jù)，用于部分復(fù)制和復(fù)制命令丟失時的數(shù)據(jù)補救。

每個 Redis 節(jié)點啟動后都會動態(tài)分配一個 40 位的十六進(jìn)制字符串作為運行 ID。運行 ID 的主要作用是用來唯一標(biāo)識 Redis 節(jié)點，比如說從節(jié)點保存主節(jié)點的運行 ID 來識別自己正在復(fù)制的時哪個主節(jié)點。

全量同步

`slaveof` 命令的執(zhí)行

1) 從節(jié)點發(fā)送 psync 命令進(jìn)行數(shù)據(jù)同步，由于是第一次進(jìn)行復(fù)制，從節(jié)點沒有復(fù)制偏移量和主節(jié)點的運行ID，所以發(fā)送的命令時 PSYNC ? -1。
2) 主節(jié)點根據(jù) PSYNC ? -1 解析出當(dāng)前為全量復(fù)制，回復(fù) + FULLRESYNC 響應(yīng)。
3) 從節(jié)點接收主節(jié)點的響應(yīng)數(shù)據(jù)保存運行 ID 和偏移量 offset。
4) 主節(jié)點執(zhí)行 bgsave 保存 RDB 文件到本地，有關(guān) RDB 的知識可以查看《Redis RDB 持久化詳解》
5) 主節(jié)點發(fā)送 RDB 文件給從節(jié)點，從節(jié)點把接收的 RDB 文件保存在本地并直接作為從節(jié)點的數(shù)據(jù)文件，接收完 RDB 后從節(jié)點打印相關(guān)日志，可以在日志中查看主節(jié)點發(fā)送的數(shù)據(jù)量。

需要注意，對于數(shù)據(jù)量較大的主節(jié)點，比如生成的 RDB 文件超過 6GB 以上時要格外小心。如果傳輸 RDB 的時間超過 repl-timeout 所配置的值，從節(jié)點將發(fā)起接收 RDB 文件并清理已經(jīng)下載的臨時文件，導(dǎo)致全量復(fù)制失敗。

6) 對于主節(jié)點開始保存 RDB 快照到從節(jié)點接收完成期間，主節(jié)點仍然響應(yīng)讀命令，因此主節(jié)點會把這期間寫命令保存在復(fù)制客戶端緩沖區(qū)內(nèi)，當(dāng)從節(jié)點加載完 RDB 文件后，主節(jié)點再把緩沖區(qū)內(nèi)的數(shù)據(jù)發(fā)送給從節(jié)點，保證主從之間數(shù)據(jù)一致性。

如果主節(jié)點創(chuàng)建和傳輸 RDB 的時間過長，可能會出現(xiàn)主節(jié)點復(fù)制客戶端緩沖區(qū)溢出。默認(rèn)配置為 client-output-buffer-limit slave 256MB 64MB 60，如果60s內(nèi)緩沖區(qū)消耗持續(xù)大于64MB或者直接超過256MB時，主節(jié)點將直接關(guān)閉復(fù)制客戶端連接，造成全量同步失敗。

7) 從節(jié)點接收完主節(jié)點傳送來的全部數(shù)據(jù)后會清空自身舊數(shù)據(jù)，該步驟對應(yīng)如下日志。
8) 從節(jié)點清空數(shù)據(jù)后開始加載 RDB 文件，對于加大的 RDB 文件，這一步操作依然比較耗時，可以通過計算日志之間的時間差來判斷加載 RDB 的總耗時。
9) 收到 SYNC 命令的主服務(wù)器執(zhí)行 BGSAVE 命令，在后臺生成一個 RDB 文件，并使用一個緩沖區(qū)記錄從現(xiàn)在開始執(zhí)行的所有寫命令。
10) 當(dāng)主服務(wù)器的 BGSAVE 命令執(zhí)行完畢時，主服務(wù)器會將 GBSAVE 命令生成的 RDB 文件發(fā)送給從服務(wù)器，從服務(wù)器接收并載入這個 RDB 文件，將自己的數(shù)據(jù)庫狀態(tài)更新至主服務(wù)器執(zhí)行 BGSAVE 命令時的數(shù)據(jù)庫狀態(tài)。
11) 主服務(wù)器將記錄在緩沖區(qū)里邊的所有寫命令發(fā)送給從服務(wù)器，從服務(wù)器執(zhí)行這些寫命令，將自己的數(shù)據(jù)庫狀態(tài)更新至主服務(wù)器數(shù)據(jù)庫當(dāng)前所處的狀態(tài)。

通過分析全量復(fù)制的所有流程，讀者會發(fā)現(xiàn)全量復(fù)制是一個非常耗時費力的操作。它時間開銷主要包括：

主節(jié)點 bgsave 時間
RDB 文件網(wǎng)絡(luò)傳輸時間
從節(jié)點清空數(shù)據(jù)時間
從節(jié)點加載 RDB 的時間
可能的 AOF 重寫時間

全量同步過程中不僅會消耗大量時間，還會進(jìn)行多次持久化相關(guān)操作和網(wǎng)絡(luò)數(shù)據(jù)傳輸，這期間會大量消耗主從節(jié)點所在服務(wù)器的 CPU、內(nèi)存和網(wǎng)絡(luò)資源。所以，除了第一次復(fù)制是采用全量同步無法避免，其他場景應(yīng)該規(guī)避全量復(fù)制，采取部分同步功能。

部分同步

部分復(fù)制主要是 Redis 針對全量復(fù)制的過高開銷做出的一種優(yōu)化措施，使用 psync {runId} {offset} 命令實現(xiàn)。當(dāng)從節(jié)點正在復(fù)制主節(jié)點時，如果出現(xiàn)網(wǎng)絡(luò)閃斷或者命令丟失等異常情況時，從節(jié)點會向主節(jié)點要求補發(fā)丟失的命令數(shù)據(jù)，如果主節(jié)點的復(fù)制積壓緩沖區(qū)存在這部分?jǐn)?shù)據(jù)則直接發(fā)送給從節(jié)點，這樣就保證了主從節(jié)點復(fù)制的一致性。補發(fā)的這部分?jǐn)?shù)據(jù)一般遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù)，所以開銷很小。

1 ) 當(dāng)主從節(jié)點之間網(wǎng)絡(luò)出現(xiàn)中斷時，如果超過了 repl-timeout 時間，主節(jié)點會認(rèn)為從節(jié)點故障并中斷復(fù)制連接。
2) 主從連接中斷期間主節(jié)點依然響應(yīng)命令，但因復(fù)制連接中斷命令無法發(fā)送給從節(jié)點，不過主節(jié)點內(nèi)部存在復(fù)制積壓緩沖區(qū)( repl-backlog-buffer )，依然可以保存最近一段時間的寫命令數(shù)據(jù)，默認(rèn)最大緩存 1MB。
3) 當(dāng)主從節(jié)點網(wǎng)絡(luò)恢復(fù)后，從節(jié)點會再次連上主節(jié)點。
4) 當(dāng)主從連接恢復(fù)后，由于從節(jié)點之前保存了自身已復(fù)制的偏移量和主節(jié)點的運行ID。因此會把它們作為 psync 參數(shù)發(fā)送給主節(jié)點，要求進(jìn)行補發(fā)復(fù)制操作。
5) 主節(jié)點接到 psync 命令后首先核對參數(shù) runId 是否與自身一致，如果一致，說明之前復(fù)制的是當(dāng)前主節(jié)點；之后根據(jù)參數(shù) offset 在自身復(fù)制積壓緩沖區(qū)查找，如果偏移量之后的數(shù)據(jù)存在緩沖區(qū)中，則對從節(jié)點發(fā)送 +CONTINUE 響應(yīng)，表示可以進(jìn)行部分復(fù)制。
6) 主節(jié)點根據(jù)偏移量把復(fù)制積壓緩沖區(qū)里的數(shù)據(jù)發(fā)送給從節(jié)點，保證主從復(fù)制進(jìn)入正常狀態(tài)。

心跳檢測

主從節(jié)點在建立復(fù)制后，它們之間維護(hù)著長連接并彼此發(fā)送心跳命令，如下圖所示。

主從心跳判斷機制如下所示：

1) 主從節(jié)點彼此都有心跳檢測機制，各自模擬成對方的客戶端進(jìn)行通信，通過 client list 命令查看復(fù)制相關(guān)客戶端信息，主節(jié)點的連接狀態(tài)為 flags=M，從節(jié)點連接狀態(tài)為 flags=S。
2) 主節(jié)點默認(rèn)每隔 10 秒對從節(jié)點發(fā)送 ping 命令，判斷從節(jié)點的存活性和連接狀態(tài)?？梢酝ㄟ^參數(shù) repl-ping-slave-period 控制發(fā)送頻率。
3) 從節(jié)點在主線程中每隔 1 秒發(fā)送 replconf ack { offset } 命令，給主節(jié)點上報自己當(dāng)前的復(fù)制偏移量。

replconf 命令不僅能實時監(jiān)測主從節(jié)點網(wǎng)絡(luò)狀態(tài)，還能上報從節(jié)點復(fù)制偏移量。主節(jié)點會根據(jù)從節(jié)點上傳的偏移量檢查復(fù)制數(shù)據(jù)是否丟失，如果從節(jié)點數(shù)據(jù)丟失，再從主節(jié)點的復(fù)制緩存區(qū)中拉取丟失的數(shù)據(jù)發(fā)送給該從節(jié)點。