本文節選自《300分鐘吃透分布式緩存》27講
作者：陳波
我們知道，當有多臺 redis 服務器時，肯定就有一臺主服務器和多臺從服務器。一般來說，主服務器進行寫操作，從服務器進行讀操作。
那么，從服務器如何和主服務器進行數據同步的呢？
其實就是通過主從復制來實現的。
本篇內容主要分享 Redis 復制原理，以及復制分析等內容。
Redis 復制原理
為了避免單點故障，數據存儲需要進行多副本構建。同時由于 Redis 的核心操作是單線程模型的，單個 Redis 實例能處理的請求 TPS 有限。因此 Redis 自面世起，基本就提供了復制功能，而且對復制策略不斷進行優化。
通過數據復制，Redis 的一個 master 可以掛載多個 slave，而 slave 下還可以掛載多個 slave，形成多層嵌套結構。所有寫操作都在 master 實例中進行，master 執行完畢后，將寫指令分發給掛在自己下面的 slave 節點。slave 節點下如果有嵌套的 slave，會將收到的寫指令進一步分發給掛在自己下面的 slave。
通過多個 slave，Redis 的節點數據就可以實現多副本保存，任何一個節點異常都不會導致數據丟失，同時多 slave 可以 N 倍提升讀性能。master 只寫不讀，這樣整個 master-slave 組合，讀寫能力都可以得到大幅提升。
master 在分發寫請求時，同時會將寫指令復制一份存入復制積壓緩沖，這樣當 slave 短時間斷開重連時，只要 slave 的復制位置點仍然在復制積壓緩沖，則可以從之前的復制位置點之后繼續進行復制，提升復制效率。
主庫 master 和從庫 slave 之間通過復制 id 進行匹配，避免 slave 掛到錯誤的 master。Redis 的復制分為全量同步和增量同步。
Redis 在進行全量同步時，master 會將內存數據通過 bgsave 落地到 rdb，同時，將構建 內存快照期間 的寫指令，存放到復制緩沖中，當 rdb 快照構建完畢后，master 將 rdb 和復制緩沖隊列中的數據全部發送給 slave，slave 完全重新創建一份數據。
這個過程，對 master 的性能損耗較大，slave 構建數據的時間也比較長，而且傳遞 rdb 時還會占用大量帶寬，對整個系統的性能和資源的訪問影響都比較大。
而增量復制，master 只發送 slave 上次復制位置之后的寫指令，不用構建 rdb，而且傳輸內容非常有限，對 master、slave 的負荷影響很小，對帶寬的影響可以忽略，整個系統受影響非常小。
在 Redis 2.8 之前，Redis 基本只支持全量復制。在 slave 與 master 斷開連接，或 slave 重啟后，都需要進行全量復制。在 2.8 版本之后，Redis 引入 psync，增加了一個復制積壓緩沖，在將寫指令同步給 slave 時，會同時在復制積壓緩沖中也寫一份。
在 slave 短時斷開重連后，上報master runid 及復制偏移量。如果 runid 與 master 一致，且偏移量仍然在 master 的復制緩沖積壓中，則 master 進行增量同步。
但如果 slave 重啟后，master runid 會丟失，或者切換 master 后，runid 會變化，仍然需要全量同步。
因此 Redis 自 4.0 強化了 psync，引入了 psync2。在 pysnc2 中，主從復制不再使用 runid，而使用 replid（即復制id） 來作為復制判斷依據。同時 Redis 實例在構建 rdb 時，會將 replid 作為 aux 輔助信息存入 rbd。重啟時，加載 rdb 時即可得到 master 的復制 id。從而在 slave 重啟后仍然可以增量同步。
在 psync2 中，Redis 每個實例除了會有一個復制 id 即 replid 外，還有一個 replid2。Redis 啟動后，會創建一個長度為 40 的隨機字符串，作為 replid 的初值，在建立主從連接后，會用 master的 replid 替換自己的 replid。同時會用 replid2 存儲上次 master 主庫的 replid。這樣切主時，即便 slave 匯報的復制 id 與新 master 的 replid 不同，但和新 master 的 replid2 相同，同時復制偏移仍然在復制積壓緩沖區內，仍然可以實現增量復制。
Redis 復制分析
在設置 master、slave 時，首先通過配置或者命令 slaveof no one 將節點設置為主庫。然后其他各個從庫節點，通過 slaveof $master_ip $master_port，將其他從庫掛在到 master 上。
同樣方法，還可以將 slave 節點掛載到已有的 slave 節點上。在準備開始數據復制時，slave 首先會主動與 master 創建連接，并上報信息。具體流程如下。
slave 創建與 master 的連接后，首先發送 ping 指令，如果 master 沒有返回異常，而是返回 pong，則說明 master 可用。
如果 Redis 設置了密碼，slave 會發送 auth $masterauth 指令，進行鑒權。當鑒權完畢，從庫就通過 replconf 發送自己的端口及 IP 給 master。
接下來，slave 繼續通過 replconf 發送 capa eof capa psync2 進行復制版本校驗。如果 master 校驗成功。從庫接下來就通過 psync 將自己的復制 id、復制偏移發送給 master，正式開始準備數據同步。
主庫接收到從庫發來的 psync 指令后，則開始判斷可以進行數據同步的方式。
前面講到，Redis 當前保存了復制 id，replid 和 replid2。如果從庫發來的復制 id，與 master 的復制 id（即 replid 和 replid2）相同，并且復制偏移在復制緩沖積壓中，則可以進行增量同步。master 發送 continue 響應，并返回 master 的 replid。slave 將 master 的 replid 替換為自己的 replid，并將之前的復制 id 設置為 replid2。之后，master 則可繼續發送，復制偏移位置 之后的指令，給 slave，完成數據同步。
如果主庫發現從庫傳來的復制 id 和自己的 replid、replid2 都不同，或者復制偏移不在復制積壓緩沖中，則判定需要進行全量復制。master 發送 fullresync 響應，附帶 replid 及復制偏移。然后， master 根據需要構建 rdb，并將 rdb 及復制緩沖發送給 slave。
對于增量復制，slave 接下來就等待接受 master 傳來的復制緩沖及新增的寫指令，進行數據同步。
而對于全量同步，slave 會首先進行，嵌套復制的清理工作，比如 slave 當前還有嵌套的 子slave，則該 slave 會關閉嵌套 子slave 的所有連接，并清理自己的復制積壓緩沖。
然后，slave 會構建臨時 rdb 文件，并從 master 連接中讀取 rdb 的實際數據，寫入 rdb 中。在寫 rdb 文件時，每寫 8M，就會做一個 fsync操作， 刷新文件緩沖。當接受 rdb 完畢則將 rdb 臨時文件改名為 rdb 的真正名字。
接下來，slave 會首先清空老數據，即刪除本地所有 DB 中的數據，并暫時停止從 master 繼續接受數據。然后，slave 就開始全力加載 rdb 恢復數據，將數據從 rdb 加載到內存。
在 rdb 加載完畢后，slave 重新利用與 master 的連接 socket，創建與 master 連接的 client，并在此注冊讀事件，可以開始接受 master 的寫指令了。
此時，slave 還會將 master 的 replid 和復制偏移設為自己的復制 id 和復制偏移 offset，并將自己的 replid2 清空，因為，slave 的所有嵌套 子slave 接下來也需要進行全量復制。
最后，slave 就會打開 aof 文件，在接受 master 的寫指令后，執行完畢并寫入到自己的 aof 中。
相比之前的 sync，psync2 優化很明顯。在短時間斷開連接、slave 重啟、切主等多種場景，只要延遲不太久，復制偏移仍然在復制積壓緩沖，均可進行增量同步。
master 不用構建并發送巨大的 rdb，可以大大減輕 master 的負荷和網絡帶寬的開銷。同時，slave 可以通過輕量的增量復制，實現數據同步，快速恢復服務，減少系統抖動。
但是，psync 依然嚴重依賴于復制緩沖積壓，太大會占用過多內存，太小會導致頻繁的全量復制。而且，由于內存限制，即便設置相對較大的復制緩沖區，在 slave 斷開連接較久時，仍然很容易被復制緩沖積壓沖刷，從而導致全量復制。
