Redis 複製過程詳解

Redis 的複製功能分為同步( sync )和命令傳播( command propagate )兩個步驟：

• 同步用於將從伺服器的資料庫狀態更新至主伺服器當前所處的資料庫狀態。
• 命令傳播則用於在主伺服器的資料庫狀態被修改，導致主從伺服器的資料庫狀態出現不一致時，讓主從伺服器的資料庫重新回到一致狀態。

同步

Redis 使用 psync 命令完成主從數據同步，同步過程分為：全量複製和部分複製。

全量複製：一般用於初次複製場景，它會把主節點全部數據一次性發送給從節點發送給從節點，當數據量較大時，會對主從節點和網路造成很大的開銷。

部分複製：用於處理在主從複製中因網路閃斷等原因造成的網路丟失場景，當從節點再次連接上主節點後，如果條件允許，主節點會補發丟失數據給從節點。因為補發的數據遠遠小於全量數據，可以有效避免全量複製的過高開銷。

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

• 主從節點各自複製偏移量
• 主節點複製積壓緩衝區
• 主節點運行 id

參與複製的從節點都會維護自身複製偏移量。主節點在處理完寫命令後，會把命令的位元組長度做累加記錄，統計在 info replication 中的 masterreploffset 指標中。 從節點在接收到主節點發送的命令後，也會累加記錄自身的偏移量，並且會每秒鐘上報自身的複製偏移量給主節點。 通過對比主從節點的複製偏移量，可以判斷主從節點數據是否一致。

複製積壓緩衝區是保存在主節點的一個固定長度的隊列，預設大小為 1MB，當主節點有連接的從節點時被創建。主節點響應寫命令時，不但會把命令發送給從節點，還會寫入複製積壓緩衝區中。

複製積壓緩衝區大小有限，只能保存最近的複製數據，用於部分複製和複製命令丟失時的數據補救。

每個 Redis 節點啟動後都會動態分配一個 40 位的十六進位字元串作為運行 ID。運行 ID 的主要作用是用來唯一標識 Redis 節點，比如說從節點保存主節點的運行 ID 來識別自己正在複製的時哪個主節點。

全量同步

slaveof 命令的執行

• 1) 從節點發送 psync 命令進行數據同步，由於是第一次進行複製，從節點沒有複製偏移量和主節點的運行ID，所以發送的命令時 PSYNC ? -1。
• 2) 主節點根據 PSYNC ? -1 解析出當前為全量複製，回覆 + FULLRESYNC 響應。
• 3) 從節點接收主節點的響應數據保存運行 ID 和偏移量 offset。
• 4) 主節點執行 bgsave 保存 RDB 文件到本地，有關 RDB 的知識可以查看《Redis RDB 持久化詳解》
• 5) 主節點發送 RDB 文件給從節點，從節點把接收的 RDB 文件保存在本地並直接作為從節點的數據文件，接收完 RDB 後從節點列印相關日誌，可以在日誌中查看主節點發送的數據量。

需要註意，對於數據量較大的主節點，比如生成的 RDB 文件超過 6GB 以上時要格外小心。如果傳輸 RDB 的時間超過 repl-timeout 所配置的值，從節點將發起接收 RDB 文件並清理已經下載的臨時文件，導致全量複製失敗。

• 6) 對於主節點開始保存 RDB 快照到從節點接收完成期間，主節點仍然響應讀命令，因此主節點會把這期間寫命令保存在複製客戶端緩衝區內，當從節點載入完 RDB 文件後，主節點再把緩衝區內的數據發送給從節點，保證主從之間數據一致性。

如果主節點創建和傳輸 RDB 的時間過長，可能會出現主節點複製客戶端緩衝區溢出。預設配置為 client-output-buffer-limit slave 256MB 64MB 60，如果60s內緩衝區消耗持續大於64MB或者直接超過256MB時，主節點將直接關閉複製客戶端連接，造成全量同步失敗。

• 7) 從節點接收完主節點傳送來的全部數據後會清空自身舊數據，該步驟對應如下日誌。
• 8) 從節點清空數據後開始載入 RDB 文件，對於加大的 RDB 文件，這一步操作依然比較耗時，可以通過計算日誌之間的時間差來判斷載入 RDB 的總耗時。
• 9) 收到 SYNC 命令的主伺服器執行 BGSAVE 命令，在後臺生成一個 RDB 文件，並使用一個緩衝區記錄從現在開始執行的所有寫命令。
• 10) 當主伺服器的 BGSAVE 命令執行完畢時，主伺服器會將 GBSAVE 命令生成的 RDB 文件發送給從伺服器，從伺服器接收並載入這個 RDB 文件，將自己的資料庫狀態更新至主伺服器執行 BGSAVE 命令時的資料庫狀態。
• 11) 主伺服器將記錄在緩衝區裡邊的所有寫命令發送給從伺服器，從伺服器執行這些寫命令，將自己的資料庫狀態更新至主伺服器資料庫當前所處的狀態。

通過分析全量複製的所有流程，讀者會發現全量複製是一個非常耗時費力的操作。它時間開銷主要包括：

• 主節點 bgsave 時間
• RDB 文件網路傳輸時間
• 從節點清空數據時間
• 從節點載入 RDB 的時間
• 可能的 AOF 重寫時間

全量同步過程中不僅會消耗大量時間，還會進行多次持久化相關操作和網路數據傳輸，這期間會大量消耗主從節點所在伺服器的 CPU、記憶體和網路資源。所以，除了第一次複製是採用全量同步無法避免，其他場景應該規避全量複製，採取部分同步功能。

部分同步

部分複製主要是 Redis 針對全量複製的過高開銷做出的一種優化措施，使用 psync {runId} {offset} 命令實現。當從節點正在複製主節點時，如果出現網路閃斷或者命令丟失等異常情況時，從節點會向主節點要求補發丟失的命令數據，如果主節點的複製積壓緩衝區存在這部分數據則直接發送給從節點，這樣就保證了主從節點複製的一致性。補發的這部分數據一般遠遠小於全量數據，所以開銷很小。

• 1 ) 當主從節點之間網路出現中斷時，如果超過了 repl-timeout 時間，主節點會認為從節點故障並中斷複製連接。

• 2) 主從連接中斷期間主節點依然響應命令，但因複製連接中斷命令無法發送給從節點，不過主節點內部存在複製積壓緩衝區( repl-backlog-buffer )，依然可以保存最近一段時間的寫命令數據，預設最大緩存 1MB。

• 3) 當主從節點網路恢復後，從節點會再次連上主節點。

• 4) 當主從連接恢復後，由於從節點之前保存了自身已複製的偏移量和主節點的運行ID。因此會把它們作為 psync 參數發送給主節點，要求進行補發複製操作。

• 5) 主節點接到 psync 命令後首先核對參數 runId 是否與自身一致，如果一致，說明之前複製的是當前主節點；之後根據參數 offset 在自身複製積壓緩衝區查找，如果偏移量之後的數據存在緩衝區中，則對從節點發送 +CONTINUE 響應，表示可以進行部分複製。

• 6) 主節點根據偏移量把複製積壓緩衝區里的數據發送給從節點，保證主從複製進入正常狀態。

心跳檢測

主從節點在建立複製後，它們之間維護著長連接並彼此發送心跳命令，如下圖所示。

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

• 1) 主從節點彼此都有心跳檢測機制，各自模擬成對方的客戶端進行通信，通過 client list 命令查看複製相關客戶端信息，主節點的連接狀態為 flags=M，從節點連接狀態為 flags=S。
• 2) 主節點預設每隔 10 秒對從節點發送 ping 命令，判斷從節點的存活性和連接狀態。可以通過參數 repl-ping-slave-period 控制發送頻率。
• 3) 從節點在主線程中每隔 1 秒發送 replconf ack { offset } 命令，給主節點上報自己當前的複製偏移量。

replconf 命令不僅能實時監測主從節點網路狀態，還能上報從節點複製偏移量。主節點會根據從節點上傳的偏移量檢查複製數據是否丟失，如果從節點數據丟失，再從主節點的複製緩存區中拉取丟失的數據發送給該從節點。

非同步複製和命令傳播

主節點不但負責數據讀寫，還負責把寫命令同步給從節點。寫命令的發送過程是非同步完成，也就是說主節點自身處理完寫命令後直接返回給客戶端，並不等待從節點複製完成。

這個非同步過程由命令傳播來處理，它不僅會將寫命令發送給所有從伺服器，還會將寫命令入隊到複製積壓緩衝區裡邊。

後記

個人博客，歡迎來玩