Redis系列(四)：Redis的復制機制(主從復制)

本篇博客是Redis系列的第4篇，主要講解下Redis的主從復制機制。

本系列的前3篇可以點擊以下鏈接查看：

Redis系列(一)：Redis簡介及環境安裝

Redis系列(二)：Redis的5種數據結構及其常用命令

Redis系列(三)：Redis的持久化機制(RDB、AOF)

Redis的主從復制是面試中經常會被問的，我最近面試的幾家公司只要聊到Redis，都會問我主從復制的原理。

1. 為什么需要主從復制？

在本系列的上一篇博客中，我們講到了Redis的持久化機制，它很好的解決了單台Redis服務器由於意外情況導致Redis服務器進程退出或者Redis服務器宕機而造成的數據丟失問題。

但持久化機制還原數據有個前提：你的Redis服務器得能正常啟動。

如果遇到極端的斷電情況（雖然概率小，但是有可能），Redis服務器啟都啟動不了，怎么還原數據？怎么保證它的高可用。

就算Redis服務器能啟動了，網絡連接也有崩掉的可能，我不信你沒看到過電纜被挖斷導致的某些服務不可用的新聞。

正是由於有這樣的風險，所以生產環境Redis服務器不可能使用單台的，那既然使用多台Redis服務器，多台Redis服務器之間的數據如何同步呢？

這就需要用到Redis的復制機制。

還有個原因就是，雖然Redis的性能很好，但單台畢竟還是有瓶頸的，使用主從復制可以實現讀寫分離，提高Redis的高可用性，即主服務器用來執行寫命令，多個從服務器用來執行讀命令，類似於數據庫的讀寫分離。

綜上所述，主從復制主要有以下2個使用場景：

1. 數據備份
2. 讀寫分離

2. 主從復制實踐

首先，我在本機開啟2個Redis實例（也可以搞2台Redis服務器），分別為127.0.0.1:6379、127.0.0.1:6380。

然后，使用redis-cli連接Redis實例127.0.0.1:6380並執行如下命令：

SLAVEOF 127.0.0.1 6379

此時，我們稱127.0.0.1:6379為127.0.0.1:6380的主服務器(master)，稱127.0.0.1:6380為127.0.0.1:6379的從服務器(slave)。

2者之間的關系如下所示：

然后，我們在主服務器上執行如下寫命令：

SET msg "hello world"

此時，我們不僅能在主服務器上獲取到該值，也能在從服務器上獲取到該值：

然后，我們在主服務器上執行如下刪除命令：

DEL msg

此時，我們會發現不僅主服務器上的msg鍵被刪除，從服務器上的msg也被刪除：

所以說，進行復制中的主從服務器雙方的數據庫將保存相同的數據。

值得注意的是，從服務器只能執行讀命令，執行寫命令時會報如下錯誤：

如果從服務器不想再復制主服務器，可以執行命令：SLAVEOF no one。

3. 舊版復制功能的實現(SYNC)

這里的舊版指的是Redis 2.8以前的版本。

Redis的復制功能分為以下2個操作：

1. 同步：用於將從服務器的數據庫狀態更新至主服務器當前所處的數據庫狀態。
2. 命令傳播：用於在主服務器的數據庫狀態被修改，導致主從服務器的數據庫狀態不一致時，讓主從服務器的數據庫狀態重新回到一致狀態。

3.1 同步

當客戶端向從服務器發送SLAVEOF命令，要求從服務器復制主服務器時，從服務器會向主服務器SYNC命令，該命令的執行步驟如下所示：

1. 從服務器向主服務器發送SYNC命令。
2. 主服務器收到SYNC命令后，執行BGSAVE命令，在后台生成RDB文件，並使用一個緩沖區記錄從現在開始執行的所有寫命令。
3. 當主服務器的BGSAVE命令執行完成，主服務器將生成的RDB文件發送給從服務器，從服務器接收並載入這個RDB文件，至此，從服務器的數據庫狀態和主服務器執行BGSAVE命令時的數據庫狀態一致。
4. 主服務器將記錄在緩沖區里面的所有寫命令發送給從服務器，從服務器接收並執行這些寫命令，至此，從服務器的數據庫狀態和主服務器當前的數據庫狀態一致。

SYNC命令執行期間，主從服務器的通信過程如下圖所示：

3.2 命令傳播

在同步操作執行完畢后，主從服務器的數據庫狀態達到一致狀態，當主服務器執行了客戶端發送的寫命令時，主服務器的數據庫就被修改了，導致主從服務器的數據庫狀態不再一致。

為了讓主從服務器的數據庫狀態再次回到一致狀態，主服務器需要對從服務器執行命令傳播操作：主服務器會將自己執行的寫命令，發送給從服務器執行，當從服務器執行了相同的寫命令后，主從服務器的數據庫狀態再次回到一致狀態。

舉個具體的例子，比如主從服務器剛開始都擁有k1、k2、k3、k4、k5這5個鍵，然后客戶端往主服務器發送了命令DEL k3，此時主服務器會執行該條命令，並將該條命令傳播給從服務器執行，從而使主從服務器的數據庫狀態保持一致。

整個變化過程如下所示：

4. 舊版復制功能的缺陷

這里的舊版指的是Redis 2.8以前的版本。

在Redis 2.8以前，從服務器對主服務器的復制分為以下2種情況：

1. 初次復制

   從服務器以前沒有復制過任何主服務器，或者從服務器當前要復制的主服務器和上一次復制的主服務器不同。

2. 斷線后重復制

   處於命令傳播階段的主從服務器因為網絡原因而中斷了復制，但從服務器通過重試又重新連上了主服務器，並繼續復制主服務器。

舊版復制功能可以很好的完成初次復制，但完成斷線后重復制的效率卻很低。

舉個具體的例子，從服務器B一直在復制着主服務器A，剛開始都是正常的，主服務器A執行的寫命令也都通過命令

傳播的方式傳遞給了從服務器B執行，但突然因為網絡原因，主服務器A和從服務器B之間中斷了復制，在這期間，

假設主服務器又執行了10個寫命令，然后從服務器B通過重試又重新連上了主服務器A，繼續開始復制，那么它是

怎么復制的呢？

從服務器B會向主服務器A發送SYNC命令，主服務器A接收到命令后會執行BGSAVE命令，BGSAVE命令執行期間的

所有寫命令會被記錄到緩沖區，待BGSAVE命令執行完畢后，主服務器A會將生成的RDB文件發送給從服務器B，

從服務器B接收並載入這個RDB文件，然后主服務器A將緩沖區里的寫命令發送給從服務器B執行，至此，主從

服務器的數據庫狀態又恢復一致，后續又進入命令傳播階段。

也就是說，每次斷線后重復制，都要執行一次SYNC命令來一次全量復制，但其實從服務器B需要的只是斷開連接期間主服務器A執行的寫命令，按上面的例子，也就是只需要10個寫命令即可。

而SYNC命令又是一個非常耗費資源的操作：

1. 主服務器需要執行BGSAVE命令生成RDB文件，這會耗費主服務器大量的CPU、內存和磁盤IO資源。
2. 主服務器需要將生成的RDB文件發送給從服務器，這會耗費主從服務器大量的網絡資源（帶寬和流量）。
3. 接收到RDB文件的從服務器需要載入RDB文件，在載入期間，從服務器會阻塞，沒辦法處理命令請求。

5. 新版復制功能的實現(PSYNC)

這里的新版指的是Redis 2.8以及之后的版本。

從Redis 2.8版本開始，Redis使用PSYNC命令代替SYNC命令來執行復制時的同步操作。

PSYNC命令有以下2種場景：

1. 完整重同步

   完整重同步用於處理初次復制，執行步驟和SYNC命令的執行步驟基本一樣。

2. 部分重同步

   部分重同步用於處理斷線后重復制，當從服務器在斷線后重新連接主服務器時，如果條件允許，主服務器可以將主從服務器連接斷開期間執行的寫命發送給從服務器，從服務器只要接收並執行這些寫命令，就可以將數據庫更新至主服務器當前所處的狀態。

仍然用上面舉的例子，新版復制，主服務器只需要把斷開期間執行的10個寫命令發送給從服務器即可，而不用生成並發送整個RDB文件，性能大大提升。

主從服務器在執行部分重同步時的通信過程如下圖所示：

那么部分重同步是如何實現的呢？

部分重同步功能由以下3個部分組成：

1. 主服務器和從服務器的復制偏移量
2. 主服務器的復制積壓緩沖區
3. 服務器的運行ID

接下來我們一一講解。

5.1 復制偏移量

執行復制的主服務器和從服務器會分別維護一個復制偏移量：

1. 主服務器每次向從服務器傳播N個字節的數據時，就將自己的復制偏移量的值加上N。
2. 從服務器每次收到主服務器傳播來的N個字節的數據時，就將自己的復制偏移量的值加上N。

舉個例子，假設主服務器有3個從服務器，它們的復制偏移量都為10086，如下圖所示：

然后，主服務器向3個從服務器傳播了長度為33字節的數據，那么主服務器的復制偏移量會加上33，變為10119，

從服務器A在這時剛好斷線了，沒有接收到數據，所以偏移量仍然為10086，

從服務器B和從服務器C正常接收到了數據，所以偏移量都更新為了10019，如下圖所示：

很顯然，通過對比主從服務器的復制偏移量，可以很容易地知道主從服務器是否處於一致狀態。

然后，從服務器A通過重試又重新連接到了主服務器，然后向主服務器發送PSYNC命令，並報告了自己當前的復制

偏移量為10086，主服務器此時需要處理2個問題：

1. 該對從服務器A執行完整重同步還是部分重同步？
2. 如果執行部分重同步，主服務器從哪里獲取到斷線期間從服務器A丟失的數據？

帶着這2個問題，我們看下復制積壓緩沖區。

5.2 復制積壓緩沖區

復制積壓緩沖區是主服務器維護的一個固定長度先進先出隊列，默認大小為1MB。

當主服務器進行命令傳播時，它不僅會將寫命令發送給所有從服務器，還會將寫命令入隊到復制積壓緩沖區，如下圖所示：

所以，主服務器的復制積壓緩沖區會保存着一部分最近傳播的寫命令，並且為隊列中的每個字節記錄相應的復制偏移量，如下所示：

偏移量	...	10087	10088	10089	10090	10091	...
字節值	...	'*'	3	'\r'	'\n'	'$'	...

當從服務器重新連接上主服務器時，會通過PSYNC命令將自己的復制偏移量offset發送給主服務器，主服務器會根據以下規則來決定對從服務器執行何種同步操作：

• 如果offset偏移量之后的數據仍然存在於復制積壓緩沖區，那么主服務器將對從服務器執行部分重同步操作。
• 如果offset偏移量之后的數據已經不存在於復制積壓緩沖區，那么主服務器將對從服務器執行完整重同步操作。

回到之前的例子：

1. 從服務器A重新連接上主服務器，向主服務器發送PSYNC命令，報告自己的復制偏移量為10086。
2. 主服務器收到PSYNC命令以及偏移量10086之后，會檢查偏移量10086之后的數據是否存在於復制積壓緩沖區，結果發現數據還在，於是主服務器向從服務器A發送+CONTINUE回復，表示數據同步將以部分重同步模式來進行。
3. 接着主服務器會將復制積壓緩沖區里10086偏移量之后的所有數據（偏移量為10087到10119）都發送給從服務器A。
4. 從服務器A接收這33字節的缺失數據，就回到與主服務器一致的狀態。

5.3 服務器運行ID

每個Redis服務器，不論主服務器還是從服務器，都會有自己的運行ID，運行ID在服務器啟動時自動生成，由40個十六進制字符組成，如下圖所示：

當從服務器對主服務器進行初次復制時，主服務器會將自己的運行ID傳送給從服務器，從服務器會將這個運行ID保存起來。

當從服務器斷線並重新連接上主服務器時，從服務器會把之前保存的運行ID發送給當前連接的主服務器：

• 如果從服務器之前保存的運行ID和當前連接的主服務器的運行ID相同，說明從服務器斷線前后復制的是同一台主服務器，主服務器可以繼續嘗試執行部分重同步操作。
• 如果從服務器之前保存的運行ID和當前連接的主服務器的運行ID不相同，說明從服務器斷線前后復制的不是同一台主服務器，主服務器將對從服務器執行完整重同步操作。

5.4 PSYNC命令執行細節

對於從服務器來說，調用PSYNC命令有以下2種情況：

1. 如果從服務器以前沒有復制過任何主服務器，或者之前執行過SLAVEOF on one命令，那么從服務器在開始一次新的復制時將向主服務器發送PSYNC ? -1命令，主動請求主服務器進行完整重同步。

2. 如果從服務器已經復制過某個主服務器，那么從服務器在開始一次新的復制時將向主服務器發送

   PSYNC {runid} {offset}命令，其中runid是上一次復制的主服務器的運行ID，offset是從服務器當前的復制偏移量。

對於主服務器來說，接收到PSYNC命令后會向從服務器返回以下3種回復中的一種：

1. 如果主服務器返回+FULLRESYNC {runid} {offset}，表示主服務器將與從服務器執行完整重同步操作，其中runid是主服務器的運行ID，從服務器會將這個ID保存起來，在下一次發送PSYNC命令時使用，offset是主服務器當前的復制偏移量，從服務器會將這個值作為自己的初始化偏移量。
2. 如果主服務器返回+CONTINUE，表示主服務器將與從服務器執行部分重同步操作，主服務器會將從服務器缺少的那部分數據發送給從服務器。
3. 如果主服務器返回-ERROR，表示主服務器的版本低於Redis 2.8，它識別不了PSYNC命令，從服務器將向主服務器發送SYNC命令，並與主服務器執行完整重同步操作。

以上描述流程可以使用以下流程圖來表示：

6. 源碼及參考

黃健宏 《Redis設計與實現》