Redis復制原理的示例分析

這篇文章主要介紹了Redis復制原理的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

前言

本文主要介紹Redis復制機制

一.配置與實踐

配置

Redis實例分為主節點（master）和從節點（slave），默認情況下都是主節點。每一個從節點只能有一個主節點，但是每一個主節點可以有多個從節點（注意數量，多個從節點會導致主節點寫命令多次發送從而過度消耗網絡帶寬，可用樹狀結構降低主節點負載）。復制是單向的，只能從主節點復制到從節點。配置復制的方式由以下3種：

• 在redis-slave.conf配置文件中加入slaveof {masterHost} {masterPort}

• 在redis-server啟動命令后加入 --slaveof {masterHost} {masterPort}

• 啟動后直接使用命令slaveof {masterHost} {masterPort}

綜上，Redis支持在啟動之前配置，也支持運行中動態配置。

實踐

我們用動態配置的方法來配置，先起一個端口為6379的Redis實例，作為主節點：

redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis.conf

再起一個端口為6380的Redis實例，作為6379的從節點：

redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis-slave.conf

用客戶端連到從節點，使用slaveof命令，slaveof配置都是在從節點發起的。

127.0.0.1:6380> slaveof 127.0.0.1 6379

OK

從節點日志：

75585:S 06 May 16:27:50.389 * Connecting to MASTER 127.0.0.1:6379

75585:S 06 May 16:27:50.389 * MASTER <-> SLAVE sync started

75585:S 06 May 16:27:50.390 * Non blocking connect for SYNC fired the event.

75585:S 06 May 16:27:50.390 * Master replied to PING, replication can continue...

75585:S 06 May 16:27:50.390 * Trying a partial resynchronization (request 47770067272eb8101489fe7c00c8e838125c3aa3:1).

75585:S 06 May 16:27:50.392 * Full resync from master: e91e683b1e13332f97ecb9fa90ecdace460ab4ca:0

75585:S 06 May 16:27:50.392 * Discarding previously cached master state.

75585:S 06 May 16:27:50.491 * MASTER <-> SLAVE sync: receiving 215 bytes from master

75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Flushing old data

75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Loading DB in memory

75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Finished with success

主節點日志：

75553:M 06 May 16:27:50.391 * Slave 127.0.0.1:6380 asks for synchronization

75553:M 06 May 16:27:50.391 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for '47770067272eb8101489fe7c00c8e838125c3aa3', my replication IDs are '160af1c75f86edc50186e3e4a4dc6ecb5e3fa586' and '0000000000000000000000000000000000000000')

75553:M 06 May 16:27:50.391 * Starting BGSAVE for SYNC with target: disk

75553:M 06 May 16:27:50.391 * Background saving started by pid 75675

75675:C 06 May 16:27:50.395 * DB saved on disk

75553:M 06 May 16:27:50.490 * Background saving terminated with success

75553:M 06 May 16:27:50.491 * Synchronization with slave 127.0.0.1:6380 succeeded

可以看到，第一次建立復制關系的時候，主節點和從節點進行了一次全量復制，見圖：

當完成復制的建立之后，接下來主節點會持續的把寫命令發送給從節點，保證主從數據一致。

在主實例上添加新的key：

127.0.0.1:6379> set Lin 112131

OK

在從實例查看剛剛添加的key：

127.0.0.1:6380> get Lin

"112131"

只讀

由于復制只能從主節點到從節點，對于從節點的數據修改主節點無法感知，為了避免主從實例之間的數據不一致。從節點默認配置為只讀模式：

slave-read-only yes

二.工作原理

我們先講3個比較關鍵的參數：master_replid、master_repl_offset和slave_repl_offset。我們分別在master6379和slave6380上執行info replication

127.0.0.1:6379> info replication

# Replication

role:master

connected_slaves:1

slave0:ip=127.0.0.1,port=6380,state=online,offset=1093,lag=1

master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:1093

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:1

repl_backlog_histlen:1093

127.0.0.1:6380> info replication

# Replication

role:slave

master_host:127.0.0.1

master_port:6379

master_link_status:up

master_last_io_seconds_ago:9

master_sync_in_progress:0

slave_repl_offset:1107

slave_priority:100

slave_read_only:1

connected_slaves:0

master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:1107

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:1

repl_backlog_histlen:1107

master_replid是master啟動時生成的隨機字符串，用來標識主實例

master_repl_offset是復制流中的一個偏移量，master處理完寫入命令后，會把命令的字節長度做累加記錄，統計在該字段。該字段也是實現部分復制的關鍵字段。

slave_repl_offset同樣也是一個偏移量，從節點收到主節點發送的命令后，累加自身的偏移量，通過比較主從節點的復制偏移量可以判斷主從節點數據是否一致。

當從實例連接到主實例時，從實例會發送master_replid和master_repl_offset（標識與主實例同步的最后一個快照）請求部分復制。如果主實例接收部分復制的話則從最后一個偏移量開始增量進行部分復制，否則將進行全量復制。如圖：

三.數據同步

Redis在2.8之前使用sync命令完成主從數據同步，Redis在2.8及以上使用psync命令完成主從數據同步，同步過程分為：全量復制和部分復制

全量復制

全量復制是Redis最早支持的復制方式，也是主從第一次建立復制的時候必須經歷的。它會把主節點全部數據一次性發送給從節點，當數據量較大的時候，會對主從節點和網絡造成很大開銷。主節點執行bgsave保存RDB文件，然后將這個文件發送給從節點，從節點收到RDB文件后，會先將內存中的所有數據清除，然后再將RDB文件中的數據導入。

主實例在復制過程中是完全異步的，因此不會阻塞主節點的請求。在這一期間內主節點的所有寫入命令數據都保存在從客戶端緩沖區（slave client buffer）內，在從節點加載完RDB文件后，主節點會將這個緩沖區的內容發送給從節點。

從客戶端緩沖區默認大小限制為：

client-output-buffer-limit slave 256mb 64mb 60

意思是如果60秒內緩沖區消耗持續大于64MB或者直接超過256MB時，主節點將直接關閉復制客戶端連接，造成全量同步失敗。

部分復制

在高版本的Redis實現中，master_replid和offset存儲在RDB文件中。當從實例在復制過程中，因網絡閃斷等原因造成的數據丟失場景，Redis能夠從rdb文件中重新加載master_replid和offset，從而使部分重新同步成為可能。因為補發的數據遠小于全量數據，所以可以有效的避免全量復制帶來的負載和消耗。

之前說過，從節點連接主節點之后，會使用master_replid和master_repl_offset請求主節點，首先判斷master_replid是否和自己的master_replid一致，然后檢查請求中的master_repl_offset是否能從緩沖區（replication backlog）中獲取，如果偏移量在backlog范圍內，那么可以進行部分復制。如果在斷開連接期間主節點收到的寫入命令的數量超過了backlog緩沖區的容量，那么會進行全量復制。默認情況下backlog為1MB。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Redis復制原理的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!