Redis 複製過程詳解

做者：程序員歷小冰
原文：https://mp.weixin.qq.com/s/0VVYTyAI1egfs2Fxcrme3A複製代碼

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) 主節點根據偏移量把複製積壓緩衝區裏的數據發送給從節點，保證主從複製進入正常狀態。

• 加q羣：478052716 免費領取（Java架構資料，視頻資料，BATJ面試資料）

心跳檢測

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

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

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

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

異步複製和命令傳播

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

這個異步過程由命令傳播來處理，它不只會將寫命令發送給全部從服務器，還會將寫命令入隊到複製積壓緩衝區裏邊。