redis主從復制的實現方法是什么

本篇內容介紹了“redis主從復制的實現方法是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1 簡介

這篇文章主要講述Redis的主從復制功能。會依次從環境搭建、功能測試和原理分析幾個方面進行介紹。

2 準備工作

服務器架構圖如下 

啟動主服務器101，使用info replication命令查看狀態，可以看到role為master（也就是角色為主主服務器），connected_salaves的值為0（從服務器數量為0） 

接下來用修改配置文件的方式將102機器加入的主從復制當中

然后再用命令的方式同樣將103機器加入的主從復制當中。

2.1 用修改配置文件的方式將102機器加入到主從

ip地址為192.168.17.102的機器的Redis配置文件增加slaveof 192.168.17.101 6379 
啟動102的redis，狀態如下 

可以看到role變為slave（角色為從服務器），master_host（主服務器IP地址）為192.168.17.101，master_port（主服務器端口）為6379。 
此時101主服務器的主從狀態如下,可以看到connected_salaves的值變為1，以及增加了一行slave0（從服務器的狀態） 

2.2 用命令的方式將103機器加入到主從

未執行slaveof命令的主從狀態如下 

開始執行slaveof命令

192.168.17.103:6379> slaveof 192.168.17.101 6379OK

再次查看狀態，可以看到角色已經變成從服務器 

現在再來看看主服務器的狀態，可以看到從服務器數量變成2，又多了一條從服務器的信息 

到這里主從環境就搭好了，現在來測試一波

2.3 測試

現在主服務器101輸入命令

192.168.17.101:6379> set 101 101OK

然后在從服務器102上查看所有的鍵，發現有鍵101，接著設置鍵102

192.168.17.102:6379> keys *1) "101"192.168.17.102:6379> get 101"101"192.168.17.102:6379> set 102 102(error) READONLY You can't write against a read only slave.

發現出現錯誤(error) READONLY You can't write against a read only slave. 后面在講述出錯原因

現在在從服務器103上查看所有的鍵，發現也有101

192.168.17.103:6379> keys *
1) "101"

再向主服務器101輸入命令

192.168.17.101:6379> set ip ipOK

然后到從服務器103上查看所有的鍵

192.168.17.103:6379> keys *
1) "101"
2) "ip"

可以看到多了一個鍵，說明主服務的數據同步到了從服務器上，操作過程看下圖 

2.4 其他

2.4.1 (error) READONLY You can't write against a read only slave.

出現錯誤(error) READONLY You can't write against a read only slave. 是因為
從節點默認是只讀的，如需修改可以再配置文件中修改下面這個屬性

slave-read-only yes

2.4.2 主服務器設置密碼

當主服務設置密碼時，配置文件需要增加如需參數

masterauth <master-password>

3 實現原理

當我在從服務器103上輸入slaveof命令時，出現如下日志 

總的來說主從復制功能的詳細步驟可以分為7個步驟：

1. 設置主服務器的地址和端口

2. 建立套接字連接

3. 發送PING命令

4. 身份驗證

5. 發送端口信息

6. 同步

7. 命令傳播

接下來分別敘述每個步驟

3.1設置主服務器的地址和端口

主從復制的第一步就是設置主服務器的地址和端口，當輸入slaveof命令或者在配置文件中配置信息時，從服務器會將主服務器的ip地址和端口號保存到服務器狀態的屬性里面。

3.2 建立套接字連接

在slaveof命令執行之后，從服務器會根據設置的ip和端口，向主服務器簡歷socket連接。

3.3 發送PING命令

socket連接成功后，從服務器會發送一PING命令給主服務器。

這時候PING命令可以檢查socket的讀寫狀態是否正常，還可以檢查主服務器能否正常處理命令請求。

從服務器在發送PING命令時可能遇上的情況如下圖

3.4 身份驗證

從服務器收到主服務器的PONG回復后，會檢查從服務器是否設置masterauth，設置則進行身份驗證，未設置則跳過該步驟。從服務器在身份驗證時可能遇上的情況如下

3.5 發送端口信息

身份驗證通過后，從服務器會向主服務器發送自己的監聽端口號。主服務器收到之后會將端口號記錄到從服務器對應的狀態屬性中。在主服務器調用info replication可以看到從服務器的port，如下

3.6 同步

發送端口信息之后，從服務器會向主服務器發送PSYNC命令，執行同步操作，并將自己的數據庫同步至主服務器數據庫當前的狀態。

同步這塊內容會在后面詳細描述

3.7 命令傳播

當完成同步操作之后，主從服務器便會進入命令傳播階段。這時候主從服務器的數據是一致的，當主服務器有新的寫命令時，會將改命令發送給從服務器，從服務器接收命令并執行便可以保證與主服務器的數據保持一致。 
那么Redis是如何保證主從服務器一致處于連接狀態以及命令是否丟失？ 
答：命令傳播階段，從服務器會利用心跳檢測機制定時的向主服務發送消息。 
從服務器發送的命令如下

REPLCONF ACK <replication_offset>

replication_offset表示從服務器當前的復制偏移量 
接下來看看心跳機制

3.7.1 心跳檢測機制

心跳檢測機制的作用有三個：

1. 檢查主從服務器的網絡連接狀態

2. 輔助實現min-slaves選項

3. 檢測命令丟失

3.7.1.1 檢查主從服務器的網絡連接狀態

主服務器信息中可以看到所屬的從服務器的連接信息，state表示從服務器狀態，offset表示復制偏移量，lag表示延遲值（幾秒之前有過心跳檢測機制）

3.7.1.2 輔助實現min-slaves選項

Redis.conf配置文件中有下方兩個參數

# 未達到下面兩個條件時，寫操作就不會被執行# 最少包含的從服務器# min-slaves-to-write 3# 延遲值# min-slaves-max-lag 10

如果將兩個參數的注釋取消，那么如果從服務器的數量少于3個，或者三個從服務器的延遲（lag）大于等于10秒時，主服務器都會拒絕執行寫命令。

3.7.1.3 檢測命令丟失

在從服務器的連接信息中可以看到復制偏移量，如果此時主服務器的復制偏移量與從服務器的復制偏移量不一致時，主服務器會補發缺失的數據。

4 同步原理

同步分為全量重同步和部分重同步。那么是什么決定采取全量重同步還是部分重同步操作？

4.1 全量重同步

全量重同步的步驟如下

1. 主節點收到從服務器的全量重同步請求時，主服務器便開始執行bgsave命令，同時用一個緩沖區記錄從現在開始執行的所有寫命令。

2. 當主服務器的bgsave命令執行完畢后，會將生成的RDB文件發送給從服務器。從服務器接收到RDB文件時，會將數據文件保存到硬盤，然后加載到內存中。

3. 主服務器將緩沖區所有緩存的命令發送到從服務器，從服務器接收并執行這些命令，將從服務器同步至主服務器相同的狀態。

4.2 部分重同步

要想了解部分重同步的步驟，需要先了解部分重同步所需要的幾個屬性

1. 復制偏移量

2. 復制緩沖區

3. 運行ID

4.2.1 復制偏移量

從主服務器的復制信息可以看到從服務器slave0和slave1都有一個參數offset，這個參數就是從服務器的復制偏移量。master_repl_offset這個參數就是主服務器的偏移量。如下圖

主服務器的復制偏移量保存向從服務器發送過的字節數據。 
從服務器的復制偏移量保存著從主服務器接收的字節數據。 
通過對比主服務器和從服務器的復制偏移量就可以知道命令是否丟失，丟失則補發復制偏移量相差的字節命令。 
那么這些字節數據是存放在哪里的呢？

4.2.2 復制緩沖區

這些字節數據都是存放在主服務器的復制緩沖區里的。復制緩沖區是一個固定長度（fixed-size）先進先出（FIFO）的隊列，默認大小為1MB。默認大小可以對下方的參數進行修改

# repl-backlog-size 1mb

那么復制緩沖區的數據是什么時候加入進去的呢？

答：在命令傳播階段，主節點除了將寫命令發送給從節點，還會發送一份給復制積壓緩沖區。

復制緩沖區里面會保存著一部分最傳播的寫命令和每個字節相應的復制偏移量。

由于復制緩沖區的大小是有限制的，所以保存的數據也是有限制的。如果從服務器與主服務器的復制偏移量相差的數據大于復制緩沖去存儲的數據時，同樣不會執行部分重同步。

舉個例子，主服務器的復制偏移量為20000、緩沖區能保存的數據只有5000，從服務器的復制偏移量為10000。這時從服務器與主服務器復制偏移量10000，而緩沖區只有5000，那么還是會執行全量重同步。如果相差的復制偏移量小于5000，才會執行部分重同步。

4.2.3 運行ID

每個Redis服務器啟動時，都會有自動生成自己的運行ID。 
當從服務器對主服務器進行初次復制時，主服務器會發送自己的運行ID給從服務器。 
當從服務器斷線重連時，會將之前主服務器的運行ID發送給當前連接的主服務器。這時候會出現下面兩種情況

1. 運行ID和主服務器一致，主服務器可以嘗試執行部分重同步操作。

2. 運行ID和主服務器不一致，說明之前連接的主服務器與這次連接不同，開始執行全量重同步操作。

5 相關配置

################################# REPLICATION ################################## slaveof <主服務器ip> <主服務器端口># slaveof <masterip> <masterport># masterauth <主服務器Redis密碼># masterauth <master-password># 當slave丟失master或者同步正在進行時，如果發生對slave的服務請求# yes則slave依然正常提供服務# no則slave返回client錯誤："SYNC with master in progress"slave-serve-stale-data yes# 指定slave是否只讀slave-read-only yes# 無硬盤復制功能repl-diskless-sync no# 無硬盤復制功能間隔時間repl-diskless-sync-delay 5# 從服務器發送PING命令給主服務器的周期# repl-ping-slave-period 10# 超時時間# repl-timeout 60# 是否禁用socket的NO_DELAY選項repl-disable-tcp-nodelay no# 設置主從復制容量大小，這個backlog 是一個用來在 slaves 被斷開連接時存放 slave 數據的 buffer# repl-backlog-size 1mb# master 不再連接 slave時backlog的存活時間。# repl-backlog-ttl 3600# slave的優先級slave-priority 100# 未達到下面兩個條件時，寫操作就不會被執行# 最少包含的從服務器# min-slaves-to-write 3# 延遲值# min-slaves-max-lag 10

“redis主從復制的實現方法是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！