前言

本文主要介紹Redis復(fù)制機制

一.配置與實踐

配置

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

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

當(dāng)完成復(fù)制的建立之后，接下來主節(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"

只讀

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

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啟動時生成的隨機字符串，用來標(biāo)識主實例

master_repl_offset是復(fù)制流中的一個偏移量，master處理完寫入命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計在該字段。該字段也是實現(xiàn)部分復(fù)制的關(guān)鍵字段。

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

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

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

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

全量復(fù)制

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

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

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

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

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

部分復(fù)制

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

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

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

最新評論