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 命令不僅能實時監測主從節點網路狀態，還能上報從節點復制偏移量，主節點會根據從節點上傳的偏移量檢查復制資料是否丟失，如果從節點資料丟失，再從主節點的復制快取區中拉取丟失的資料發送給該從節點，