一、概述

    在高併發服務當中，如果使用單個Redis例項，由於Redis採用單程序單執行緒處理所有請求的方式，即每次只有一個請求在處理，後面的請求排隊，如果前面請求執行時間長了，則會影響後面所有請求。所以可以拓展到多個Redis例項，採用主從機制，一個master和多個slave，master和多個slave包含相同的資料，master負責處理寫請求，slave負責讀請求。Redis主從同步即是實現這種機制的，master處理完寫請求後，同步給多個slave，從而保證資料的最終一致性。

二、同步架構

    Redis的主從同步支援兩種機制，一種為master同步給所有slave，另外一種slave級聯同步，即master同步給一個slave，這個slave再充當偽“master”同步給下一個slave，這種機制的好處是減少master的資料傳輸量，節省master的頻寬，同時在新slave加入時或者多個slave重連時，避免全部需要master來接收，造成master資源緊張，如fork子程序執行BGSAVE。具體架構如圖：

     配置某個redis使用另外一個redis作為master也很簡單，redis.conf的配置如圖：同時slave預設也是隻讀的，但是可以接收並執行master同步過來的寫命令進行資料修改，保持與master一致。

三、全量同步

    全量同步：slave啟動或者slave斷開重連master的時候，slave會發生SYNC命令給master，master接收到該命令後，則會通過bgsave啟動一個子程序將當前時間點的master全部資料的快照寫到一個檔案中，然後傳送給slave。slave接收到之後則清空記憶體，載入這些資料。具體過程如下：

    1. slave發生SYNC命令給master，請求執行全量同步，然後slave在等待期間，根據配置（如下）可以使用舊資料響應客戶端請求或者直接報錯；

    2. master接收到SYNC請求後，通過BGSAVE啟動一個子程序將當前資料快照寫到一個快照檔案；同時主程序採用一個緩衝區儲存這段時間內的所有寫請求；注意如果同時有多個slave傳送SYNC給master，master只會執行一次BGSAVE，然後將快照檔案傳送給這些slaves；

    3. 子程序完成快照檔案的寫入，向slave傳送這個快照檔案（正常邏輯來說是子程序傳送待檢視原始碼確認）；主程序繼續採用緩衝區快取寫命令；slave接收到快照檔案後，刪除舊資料，載入新的快照資料，此期間會阻塞客戶端的請求；

    4. 子程序傳送快照檔案完畢後，主程序將緩衝區的資料以Redis命令協議形式，如DEL、SET，傳送給slave。slave載入完快照資料後，則可以開始處理客戶端的請求了。同時slave接收master傳送過來的緩衝區的寫命令並執行；

    5. 此後進入增量同步模式，不斷接收master的寫請求，實現最終一致性。

四、增量同步

    增量同步即為master每接收並執行一個寫命令都同步給所有的slave，slave接收到該寫命令後執行對自身資料的修改從而保持與master的資料一致。

五、部分同步：PSYNC

    在Redis2.8+版本，Redis的slave在與master斷開連線重連的時候，預設是使用新的PSYNC同步方法，而不是原來的SYNC，因為斷線重連時，slave是包含有資料的，只是可能落後於master，所以沒必要又進行一次全量同步。PSYNC的實現具體為：

    命令格式：

PSYNC <runid> <offset>
runid:主伺服器ID
offset:從伺服器最後接收命令的偏移量

    1. run_id：master的id，表面master身份，slave使用該slave來記住自己目前是同步哪個master；如果slave沒有儲存，則傳送PSYNC ? -1，執行全量同步；數值為40位的十六進位制字串，Redis重啟後會改變，從而保證重啟後，slave使用全量複製，保證資料安全性。

    2. replication offset：即當前執行主從同步到哪裡了，master維護自身當前同步了多少給slaves，即傳送了N個位元組給slave，則會執行offset+N；slave維護自身當前從master同步了多少，通常slave的小於或等於master的；

    3. 複製積壓緩衝區：即master已同步寫命令快取列表，master以FIFO的方式儲存最近同步給slave的資料，列表大小一定，所以如果slave重連時，slave的replication offset月master的replication offset的差值大於該列表大小，則說明slave丟失的部分資料（寫命令）不能從該列表獲取了，此時需要執行全量同步，否則master將這個差值對應列表中的資料傳送給slave，slave只需執行這些寫命令即可。

    Redis4.0推出了PSYNC2.0，具體特性再分析。

六、CAP理論

    CAP理論為：在分散式系統中，多個節點之間只能滿足CP或AP，即強一致性和高可用是不能同時滿足的。Redis的主從同步是AP的，具體對高可用的強度要求，可用通過在redis.conf配置，即有至少有多少個slaves存在和至多多少秒內沒響應，則才執行寫請求，否則報錯，配置與說明如圖：預設為關閉這個特性，即master始終接收客戶端寫請求。