Redis 的複製功能分爲同步( sync )和命令傳播( command propagate )兩個步驟：
- 同步用於將從服務器的數據庫狀態更新至主服務器當前所處的數據庫狀態。
- 命令傳播則用於在主服務器的數據庫狀態被修改，導致主從服務器的數據庫狀態出現不一致時，讓主從服務器的數據庫重新回到一致狀態。
同步
Redis 使用 psync 命令完成主從數據同步，同步過程分爲：全量複製和部分複製。
全量複製：一般用於初次複製場景，它會把主節點全部數據一次性發送給從節點發送給從節點，當數據量較大時，會對主從節點和網絡造成很大的開銷。
部分複製：用於處理在主從複製中因網絡閃斷等原因造成的網絡丟失場景，當從節點再次連接上主節點後，如果條件允許，主節點會補發丟失數據給從節點。因爲補發的數據遠遠小於全量數據，可以有效避免全量複製的過高開銷。
psync 命令運行需要以下組件支持：
- 主從節點各自複製偏移量
- 主節點複製積壓緩衝區
- 主節點運行 id
參與複製的從節點都會維護自身複製偏移量。主節點在處理完寫命令後，會把命令的字節長度做累加記錄，統計在 info replication 中的 master_repl_offset 指標中。
從節點在接收到主節點發送的命令後，也會累加記錄自身的偏移量，並且會每秒鐘上報自身的複製偏移量給主節點。
通過對比主從節點的複製偏移量，可以判斷主從節點數據是否一致。
複製積壓緩衝區是保存在主節點的一個固定長度的隊列，默認大小爲 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 命令不僅能實時監測主從節點網絡狀態，還能上報從節點複製偏移量。主節點會根據從節點上傳的偏移量檢查複製數據是否丟失，如果從節點數據丟失，再從主節點的複製緩存區中拉取丟失的數據發送給該從節點。
異步複製和命令傳播
主節點不但負責數據讀寫，還負責把寫命令同步給從節點。寫命令的發送過程是異步完成，也就是說主節點自身處理完寫命令後直接返回給客戶端，並不等待從節點複製完成。
這個異步過程由命令傳播來處理，它不僅會將寫命令發送給所有從服務器，還會將寫命令入隊到複製積壓緩衝區裏邊。
