詳解Redis復(fù)制原理
前言
本文主要介紹Redis復(fù)制機(jī)制

一.配置與實(shí)踐
配置
Redis實(shí)例分為主節(jié)點(diǎn)(master)和從節(jié)點(diǎn)(slave),默認(rèn)情況下都是主節(jié)點(diǎn)。每一個(gè)從節(jié)點(diǎn)只能有一個(gè)主節(jié)點(diǎn),但是每一個(gè)主節(jié)點(diǎn)可以有多個(gè)從節(jié)點(diǎn)(注意數(shù)量,多個(gè)從節(jié)點(diǎn)會(huì)導(dǎo)致主節(jié)點(diǎn)寫(xiě)命令多次發(fā)送從而過(guò)度消耗網(wǎng)絡(luò)帶寬,可用樹(shù)狀結(jié)構(gòu)降低主節(jié)點(diǎn)負(fù)載)。復(fù)制是單向的,只能從主節(jié)點(diǎn)復(fù)制到從節(jié)點(diǎn)。配置復(fù)制的方式由以下3種:
- 在redis-slave.conf配置文件中加入slaveof {masterHost} {masterPort}
- 在redis-server啟動(dòng)命令后加入 --slaveof {masterHost} {masterPort}
- 啟動(dòng)后直接使用命令slaveof {masterHost} {masterPort}
綜上,Redis支持在啟動(dòng)之前配置,也支持運(yùn)行中動(dòng)態(tài)配置。
實(shí)踐
我們用動(dòng)態(tài)配置的方法來(lái)配置,先起一個(gè)端口為6379的Redis實(shí)例,作為主節(jié)點(diǎn):
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis.conf
再起一個(gè)端口為6380的Redis實(shí)例,作為6379的從節(jié)點(diǎn):
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis-slave.conf
用客戶(hù)端連到從節(jié)點(diǎn),使用slaveof命令,slaveof配置都是在從節(jié)點(diǎn)發(fā)起的。
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
從節(jié)點(diǎn)日志:
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é)點(diǎn)日志:
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)系的時(shí)候,主節(jié)點(diǎn)和從節(jié)點(diǎn)進(jìn)行了一次全量復(fù)制,見(jiàn)圖:

當(dāng)完成復(fù)制的建立之后,接下來(lái)主節(jié)點(diǎn)會(huì)持續(xù)的把寫(xiě)命令發(fā)送給從節(jié)點(diǎn),保證主從數(shù)據(jù)一致。
在主實(shí)例上添加新的key:
127.0.0.1:6379> set Lin 112131
OK
在從實(shí)例查看剛剛添加的key:
127.0.0.1:6380> get Lin
"112131"
只讀
由于復(fù)制只能從主節(jié)點(diǎn)到從節(jié)點(diǎn),對(duì)于從節(jié)點(diǎn)的數(shù)據(jù)修改主節(jié)點(diǎn)無(wú)法感知,為了避免主從實(shí)例之間的數(shù)據(jù)不一致。從節(jié)點(diǎn)默認(rèn)配置為只讀模式:
slave-read-only yes
二.工作原理
我們先講3個(gè)比較關(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啟動(dòng)時(shí)生成的隨機(jī)字符串,用來(lái)標(biāo)識(shí)主實(shí)例
master_repl_offset是復(fù)制流中的一個(gè)偏移量,master處理完寫(xiě)入命令后,會(huì)把命令的字節(jié)長(zhǎng)度做累加記錄,統(tǒng)計(jì)在該字段。該字段也是實(shí)現(xiàn)部分復(fù)制的關(guān)鍵字段。
slave_repl_offset同樣也是一個(gè)偏移量,從節(jié)點(diǎn)收到主節(jié)點(diǎn)發(fā)送的命令后,累加自身的偏移量,通過(guò)比較主從節(jié)點(diǎn)的復(fù)制偏移量可以判斷主從節(jié)點(diǎn)數(shù)據(jù)是否一致。
當(dāng)從實(shí)例連接到主實(shí)例時(shí),從實(shí)例會(huì)發(fā)送master_replid和master_repl_offset(標(biāo)識(shí)與主實(shí)例同步的最后一個(gè)快照)請(qǐng)求部分復(fù)制。如果主實(shí)例接收部分復(fù)制的話(huà)則從最后一個(gè)偏移量開(kāi)始增量進(jìn)行部分復(fù)制,否則將進(jìn)行全量復(fù)制。如圖:

三.數(shù)據(jù)同步
Redis在2.8之前使用sync命令完成主從數(shù)據(jù)同步,Redis在2.8及以上使用psync命令完成主從數(shù)據(jù)同步,同步過(guò)程分為:全量復(fù)制和部分復(fù)制
全量復(fù)制
全量復(fù)制是Redis最早支持的復(fù)制方式,也是主從第一次建立復(fù)制的時(shí)候必須經(jīng)歷的。它會(huì)把主節(jié)點(diǎn)全部數(shù)據(jù)一次性發(fā)送給從節(jié)點(diǎn),當(dāng)數(shù)據(jù)量較大的時(shí)候,會(huì)對(duì)主從節(jié)點(diǎn)和網(wǎng)絡(luò)造成很大開(kāi)銷(xiāo)。主節(jié)點(diǎn)執(zhí)行bgsave保存RDB文件,然后將這個(gè)文件發(fā)送給從節(jié)點(diǎn),從節(jié)點(diǎn)收到RDB文件后,會(huì)先將內(nèi)存中的所有數(shù)據(jù)清除,然后再將RDB文件中的數(shù)據(jù)導(dǎo)入。
主實(shí)例在復(fù)制過(guò)程中是完全異步的,因此不會(huì)阻塞主節(jié)點(diǎn)的請(qǐng)求。在這一期間內(nèi)主節(jié)點(diǎn)的所有寫(xiě)入命令數(shù)據(jù)都保存在從客戶(hù)端緩沖區(qū)(slave client buffer)內(nèi),在從節(jié)點(diǎn)加載完RDB文件后,主節(jié)點(diǎn)會(huì)將這個(gè)緩沖區(qū)的內(nèi)容發(fā)送給從節(jié)點(diǎn)。
從客戶(hù)端緩沖區(qū)默認(rèn)大小限制為:
client-output-buffer-limit slave 256mb 64mb 60
意思是如果60秒內(nèi)緩沖區(qū)消耗持續(xù)大于64MB或者直接超過(guò)256MB時(shí),主節(jié)點(diǎn)將直接關(guān)閉復(fù)制客戶(hù)端連接,造成全量同步失敗。
部分復(fù)制
在高版本的Redis實(shí)現(xiàn)中,master_replid和offset存儲(chǔ)在RDB文件中。當(dāng)從實(shí)例在復(fù)制過(guò)程中,因網(wǎng)絡(luò)閃斷等原因造成的數(shù)據(jù)丟失場(chǎng)景,Redis能夠從rdb文件中重新加載master_replid和offset,從而使部分重新同步成為可能。因?yàn)檠a(bǔ)發(fā)的數(shù)據(jù)遠(yuǎn)小于全量數(shù)據(jù),所以可以有效的避免全量復(fù)制帶來(lái)的負(fù)載和消耗。
之前說(shuō)過(guò),從節(jié)點(diǎn)連接主節(jié)點(diǎn)之后,會(huì)使用master_replid和master_repl_offset請(qǐng)求主節(jié)點(diǎn),首先判斷master_replid是否和自己的master_replid一致,然后檢查請(qǐng)求中的master_repl_offset是否能從緩沖區(qū)(replication backlog)中獲取,如果偏移量在backlog范圍內(nèi),那么可以進(jìn)行部分復(fù)制。如果在斷開(kāi)連接期間主節(jié)點(diǎn)收到的寫(xiě)入命令的數(shù)量超過(guò)了backlog緩沖區(qū)的容量,那么會(huì)進(jìn)行全量復(fù)制。默認(rèn)情況下backlog為1MB。
以上就是詳解Redis復(fù)制原理的詳細(xì)內(nèi)容,更多關(guān)于Redis復(fù)制原理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Redis實(shí)現(xiàn)Session共享與單點(diǎn)登錄
本文主要介紹了Redis實(shí)現(xiàn)Session共享與單點(diǎn)登錄,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2022-07-07
Redis3.2.6配置文件詳細(xì)中文說(shuō)明
本文為大家分享了Redis3.2.6配置文件詳細(xì)中文說(shuō)明,非常詳細(xì)收藏起來(lái)以后工作有用2018-10-10
利用Redis?lua實(shí)現(xiàn)高效讀寫(xiě)鎖的代碼實(shí)例
這篇文章給大家介紹了如何利用Redis?lua實(shí)現(xiàn)高效的讀寫(xiě)鎖,讀寫(xiě)鎖的好處就是能幫助客戶(hù)讀到的數(shù)據(jù)一定是最新的,寫(xiě)鎖是排他鎖,而讀鎖是一個(gè)共享鎖,需要的朋友可以參考下2024-01-01
redis key命名規(guī)范的設(shè)計(jì)
如果結(jié)構(gòu)規(guī)劃不合理、命令使用不規(guī)范,會(huì)造成系統(tǒng)性能達(dá)到瓶頸、活動(dòng)高峰系統(tǒng)可用性下降,也會(huì)增大運(yùn)維難度,本文主要介紹了redis key命名規(guī)范的設(shè)計(jì),感興趣的可以了解一下2024-03-03
RedisTemplate 實(shí)現(xiàn)基于Value 操作的簡(jiǎn)易鎖機(jī)制(示例代碼)
本文將介紹如何使用 RedisTemplate 的 opsForValue().setIfAbsent() 方法來(lái)實(shí)現(xiàn)一種簡(jiǎn)單的鎖機(jī)制,并提供一個(gè)示例代碼,展示如何在 Java 應(yīng)用中利用這一機(jī)制來(lái)保護(hù)共享資源的訪問(wèn),感興趣的朋友跟隨小編一起看看吧2024-05-05

