Redis 復制過程介紹

本篇內容介紹了“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 命令不僅能實時監測主從節點網絡狀態，還能上報從節點復制偏移量。主節點會根據從節點上傳的偏移量檢查復制數據是否丟失，如果從節點數據丟失，再從主節點的復制緩存區中拉取丟失的數據發送給該從節點。

異步復制和命令傳播

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

這個異步過程由命令傳播來處理，它不僅會將寫命令發送給所有從服務器，還會將寫命令入隊到復制積壓緩沖區里邊。

“Redis 復制過程介紹”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！