前言

本文主要介紹Redis復制機制

一.配置與實踐

配置

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

• 在redis-slave.conf配置文件中加入slaveof {masterHost} {masterPort}
• 在redis-server啟動命令后加入 --slaveof {masterHost} {masterPort}
• 啟動后直接使用命令slaveof {masterHost} {masterPort}

綜上，Redis支持在啟動之前配置，也支持運行中動態(tài)配置。

實踐

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

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

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

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

用客戶端連到從節(jié)點，使用slaveof命令，slaveof配置都是在從節(jié)點發(fā)起的。

127.0.0.1:6380> slaveof 127.0.0.1 6379

OK

從節(jié)點日志：

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

主節(jié)點日志：

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

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

當完成復制的建立之后，接下來主節(jié)點會持續(xù)的把寫命令發(fā)送給從節(jié)點，保證主從數(shù)據(jù)一致。

在主實例上添加新的key：

127.0.0.1:6379> set Lin 112131

OK

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

127.0.0.1:6380> get Lin

"112131"

只讀

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

slave-read-only yes

二.工作原理

我們先講3個比較關(guān)鍵的參數(shù)：master_replid、master_repl_offset和slave_repl_offset。我們分別在master6379和slave6380上執(zhí)行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處理完寫入命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計在該字段。該字段也是實現(xiàn)部分復制的關(guān)鍵字段。

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

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

三.數(shù)據(jù)同步

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

全量復制

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

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

從客戶端緩沖區(qū)默認大小限制為：

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

意思是如果60秒內(nèi)緩沖區(qū)消耗持續(xù)大于64MB或者直接超過256MB時，主節(jié)點將直接關(guān)閉復制客戶端連接，造成全量同步失敗。

部分復制

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

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

以上就是詳解Redis復制原理的詳細內(nèi)容，更多關(guān)于Redis復制原理的資料請關(guān)注腳本之家其它相關(guān)文章！