概述

• 在Redis2.8之前，如果從服務器在主從復制的過程中，出現了斷線，重連之后需要全量同步一次主服務器上面的數據，即從服務器發送SYNC命令給主服務器，請求進行全量同步，但是斷線重連之后，從服務器只是可能落后主服務器斷線期間的寫入或者如果斷線時間非常短，主從之間數據還是一致的，故如果簡單地進行全量同步，則會造成主從服務器之間CPU，內存，網絡帶寬方面的浪費。
• 故在Redis2.8及其之后版本，對于從服務器斷線重連主服務器這種情景，使用的是部分同步PSYNC來實現。即從服務器重連之后，發送PSYNC命令給主服務器，主服務器根據該從服務器的同步情況，決定是只需將斷線期間的寫入同步給該從服務器，還是需要進行一次全量同步。

核心設計

• 在PSYNC中，由于在主從之間只需要同步從服務器落后的部分數據，故在主從服務器中，均需要維護同步狀態相關的數據。
• PSYNC部分主從同步實現的必要組件，即同步狀態數據：
• 主從服務器的復制偏移量；
• 主服務器的復制積壓緩沖區；
• 主從服務器運行ID。

復制偏移量

• 主服務器和從服務器都維護了一個復制偏移量，對應主服務器來說，是記錄主服務器同步了多少數據給從服務器，即主服務器每進行一次寫操作，如SET key “helloworld”，都會將該寫命令同步給從服務器，而在主服務器中會計算這個命令的字節數，假如為N個，則主服務器的復制偏移量將會遞增N。
• 從服務器的復制偏移量則記錄了從服務器從主服務器同步了多少字節的數據，如當接收到主服務器的以上寫命令時，從服務器也會將自身復制偏移量遞增N。
• 所以如果主從服務器之間的復制偏移量是相等的，表示主從服務器之間數據一致；如果從服務器的小于主服務器的，則表示從服務器落后主服務器，這種情況在從服務器斷線重連之后可能會發生。具體過程如以下示意圖：(圖片均引自黃建宏的《Redis設計與實現》)

1.主服務器同步前：

2.主服務器同步后：

復制積壓緩沖區

• 復制積壓緩沖區主要用于緩存主服務器發送給從服務器的數據，在從服務器斷線重連后，從該緩沖區查找從服務器斷線期間，主服務器的寫命令數據，從而主服務器可以從該緩沖區獲取從服務器落后的數據，發送給從服務器，實現部分同步。
• 數據結構：復制積壓緩沖區是在主服務器維護的一個大小固定的FIFO的隊列，默認大小為1M。即如果超過1M，則主服務器會將隊列頭部數據出隊刪除，其中頭部數據為最先入隊數據，即最早的寫入命令數據。具體大小可以通過在配置文件redis.conf中的repl-backlog-size來修改。
• 合適大小：復制積壓緩沖區的合適大小可以根據：seconds * write_size_per_seconds來計算，其中seconds為從服務器斷開連接的平均時長，write_size_per_seconds為每秒寫(寫命令+寫的數據)的平均大小。為了安全期間通常為2 * seconds * write_size_per_seconds。
• 緩沖區的更新：主服務器的復制偏移量和復制積壓緩沖區的更新是在主服務器在每次向從服務器傳播了N個字節，則將自身的復制偏移量加上N。其中該N個字節的數據是一個寫命令(即寫命令+寫數據)。同時將該次的寫命令寫入復制積壓緩沖區中，寫命令的每個字節在復制積壓緩沖區都對應一個偏移量，如圖：

主從服務器運行ID

• 在主從同步當中，主從服務器都有自己的運行ID，運行ID是在服務器啟動時自動生成的，由40個隨機生成的16進制的字符組成。
• 服務器運行ID的主要作用是：

從服務器剛開始同步主服務器時，主服務器會將自身的運行ID發送給從服務器，從服務器在內部進行保存。(由于從服務器重啟時，沒有主服務器的運行ID，故需要進行全量同步)

之后從服務器斷線重新連接主服務器請求同步時，從服務器將之前所連接的主服務器的運行ID傳給主服務器，當前這個主服務器檢查自己的運行ID和這個從服務器傳過來的運行ID是否一致，一致則說明主服務器在斷線期間沒有更換，故進入根據復制偏移量和復制積壓緩沖區來判斷是否進行全量還是部分同步的邏輯；否則是主服務器更換過，執行全量同步。

基于PSYNC的主從同步

• 主從服務器直接進行PSYNC部分同步通常發送在從服務器斷線重連的時候，此時由從服務器發起。除此之外，在心跳檢測發現命令丟失時，主服務器也會主動發起一次PSYNC。主從同步示意圖如下：

斷線重連導致的PSYNC

• 當從服務器斷線重連之后，發送PSYNC命令、自身的復制偏移量和斷線前所同步的主服務器運行ID給主服務器，即：

PSYNC

• 主服務器根據該從服務器的復制偏移量offset和主服務器的復制積壓緩沖區是否存在該偏移量對應的數據，如果該從服務器偏移量之后(即offset+1)的數據還在該緩沖區中，則執行部分同步，將隊列中從offset+1到隊列尾的數據發送給從服務器；
• 否則如果從服務器數據落后太多，如該1M的復制積壓緩沖區的頭部的偏移量都大于該從服務器復制偏移量(即offset+1)，則執行全量同步。
• 對從服務器而言，發送完PSYNC命令之后，如果主服務器返回+CONTINUE的回復，則說明可以進行部分同步，從服務等待主服務器同步落后的數據過來，主服務器將復制積壓緩沖區中該從服務器落后的這部分數據發送過來。如果返回+FULLRESYNCH ,則進行全量同步。如果返回-ERROR，則說明主服務器版本低于2.8，不支持部分同步，此時從服務發送SYNC執行全量同步。

心跳檢測導致的PSYNC

• 在進入主從同步，主服務器和從服務器建立socket連接之后，從服務器以每秒一次的頻率向主服務器發送心跳包，即發送命令：

REPLCONF ACK

• 其中replication_offset為從服務器當前的復制偏移量，作用包括：

檢查主從服務器之間的網絡狀態：如果主服務器超過1秒沒有收到從服務器的REPLCONF ACK命令，則說明從服務器網絡出問題了；

輔助實現min-slaves選項：即min-slaves-to-write(主服務器在從服務器數量少于min-slaves-to-write時，拒絕執行寫操作)，min-slaves-max-lag(多個從服務器的延遲都大于等于min-slaves-max-lag時，拒絕執行寫操作)；主要保證主從服務器都狀態良好時，才執行寫操作，保持主從的數據一致性；

檢測命令丟失：主服務器根據從服務器發送過來的復制偏移量replication_offset來判斷發送給從服務器的命令是否丟失了，即該復制偏移量不等于主服務器的復制偏移量，則主服務器將復制積壓緩沖區對應的落后數據發給從服務器，即主服務器主動發起一次部分同步。

總結

以上是生活随笔為你收集整理的springboot redis 断线重连_Redis复制：部分同步PSYNC详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。