都在講Redis主從複製原理，我來說實踐總結

摘要：本文將演示主從複製如何配置、實現以及實現原理，Redis主從複製三大策略，全量複製、部分複製和當即複製。

本文分享自華爲雲社區《Redis主從複製實踐總結》，原文做者：A夢多啦A 。

複製簡介

Redis 做爲一門非關係型數據庫，其複製功能和關係型數據庫(MySQL)來講，功能其實都是差很少，無外乎就是實現的原理不一樣。Redis 的複製功能也是相對於其餘的內存性數據庫(memcached)所具有特有的功能。

Redis 複製功能主要的做用，是集羣、分片功能實現的基礎；同時也是 Redis 實現高可用的一種策略，例如解決單機併發問題、數據安全性等等問題。

服務介紹

在本文環境演示中，有一臺主機，啓動了兩個 Redis 示例。

實現方式

Redis 複製實現方式分爲下面三種方式:

1. 服務啓動時配置

該方式經過在啓動 Redis 服務時，經過命令行參數，進行啓動主從複製功能。該方式的弊端是不能實現配置持久化，當服務停掉以後，啓動服務時，須要添加相同的命令參數。

1.1 master 服務器事先在 redis.confg 增長 requirepass 項。

requirepass 6379

1.2 啓動從服務器。

redis-server --port 6380 --replicaof 192.168.2.102 6379

2. 命令行配置

該方式經過使用 redis-cli 進入操做行界面，進行配置。該方式的弊端是不能實現配置持久化，當服務停掉以後，啓動服務須要執行一樣的命令。

2.1 master 服務器執行。

127.0.0.1:6379> config set requirepass 6379
OK

2.2 從服務器執行。

127.0.0.1:6380> replicaof 192.168.2.102 6379
OK
127.0.0.1:6380> config set masterauth 6379
OK

3. 配置文件配置

該方式是經過 redis.conf 配置文件進行設置，可以實現配置的持久化，是一種推薦使用的方式。

3.1 配置主服務器，redis.config。

requirepass 6379

3.2 配置從服務器，redis.config。

masterauth 6379
replicaof 192.168.2.102 6379

4.配置說明

1.masterauth：設置 redis.confi 鏈接密碼，若是設置了該值。其餘客戶端在鏈接該服務器時，須要添加密碼才能夠訪問。

2.requirepass：設置主服務器的鏈接密碼，和 1 中 masterauth 一致。

3.replicaof：從服務器鏈接到服務器的 IP 地址+端口號。

效果測試

1.主服務器添加數據。

2.從服務器獲取數據。

實現原理

// uml圖
@startuml
從服務器->主服務器: 1.保存配置
從服務器->主服務器: 2.創建socket鏈接
從服務器->主服務器: 3.發送ping命令
從服務器->主服務器: 4.權限驗證
從服務器->主服務器: 5.同步數據
從服務器->主服務器: 6.持續複製數據
@enduml

主從複製主要實現的一個流程如上圖：

1.第一步，從服務器保存主服務器的配置信息，保存以後待從服務器內部的定時器執行時，就會觸發複製的流程。

2.第二步，從服務器首先會與主服務器創建一個socket套字節鏈接，用做主從通訊使用。後面主服務器發送數據給從服務器也是經過該套字節進行。

3.第三步，socket套字節鏈接成功以後，接着發送鑑權ping命令，正常的狀況下，主服務器會發送對應的響應。ping命令的做用是爲了，保證socket套字節是否能夠用，同時也是爲了驗證主服務器是否接受操做命令。

4.第四步，接着就是鑑權驗證，判斷從節點配置的主節點鏈接密碼是否正確。

5.第五步，鑑權成功以後，就能夠開始複製數據了。主服務器此時會進行全量複製，將主服務的數據所有發給從服務器，從服務器保存主服務器發送的數據。

6.接下來就是持續複製操做。主服務器會進行異步複製，一邊將寫的數據寫入自身，同時會將新的寫命令發送給從服務器。

實現策略

Redis主從複製主要分爲三種弄策略方式，不一樣的策略方式都是針對不一樣的場景下進行使用。三種場景方式分別以下:

1.全量複製。全量複製用在主從複製剛創建時或者從切主服務器時，從服務器沒有主服務器的數據，主服務器會將自身的數據經過rdb文件方式發送給從服務器，從服務器會清空自身數據，接着將主服務器發送的數據加載到自身中。

// uml圖
@startuml
從服務器->主服務器: 1.psync ? -1
主服務器->從服務器: 2.fullsync runid offset
從服務器: 3.保存 runid offset
主服務器: 4.執行bgsave生成rdb
主服務器->從服務器: 5.發送rdb
從服務器: 6.清空自身老數據
從服務器: 7.加載主服務器數據
@enduml

2.部分複製。部分複製用在一些異常狀況下，例如主從延遲、從服務宕機以後從新啓動接收主服務器發送的部分數據。

部分複製的實現主要依賴於複製緩存區、主服務的runid、主從服務器各自的複製偏移量(offset)。

複製緩存區：主服務在接收寫命令時，會將命令寫入緩存區，以便從服務器在異常狀況下，減小數據的丟失。當從服務器正常鏈接以後，主服務器會將緩存區內的數據發送給從服務器。這裏的緩存區是一個長隊列。

主服務器runid：主服務器會在每次服務啓動以後，會生成一個惟一的ID，做爲自身標識。從服務器會將該標識保存起來，發送部分複製命令時，會使用該runid。

psync runid offset

主從複製各自偏移量：主從服務在創建複製以後，都會有自身的偏移量。從節點會每秒鐘發送自身複製的偏移量給從節點，主節點在發送寫命令以後，從節點也會增長自身的複製偏移量。主節點在每次進行了寫命令以後，也會增長自身的偏移量。這裏的偏移量是經過命令的字節長度累加計算。

3.異步複製。異步複製是針對主從創建複製關係以後，主從服務器持續保持複製關係。

場景問題

1.數據安全。

// 從服務器只讀
replica-read-only yes
// 從服務器鏈接密碼
masterauth

2.數據延遲。

默認的狀況下主節點存在新數據不會當即發送給從服務器，若是開啓，則會理解發送給從服務器。默認的時間拒絕與Linux內核。

// 複製延遲
repl-disable-tcp-nodelay yes

3.主從節點鏈接狀態。

主從節點一旦創建鏈接以後，會定時模擬成對方的客戶端，檢測對方的服務狀態。主節點能夠經過設置repl-ping-replica-period配置參數進行設置。默認的頻率是10s。

從節點咋執行replconf ack {offsetid}時，也會將自身的複製偏移量發送給主服務器，主服務根據偏移量進行判斷數據延遲。存在數據延遲就會從複製積壓緩衝區的數據匯中，將對應的數據補發給從節點。

 

點擊關注，第一時間瞭解華爲雲新鮮技術~