在當(dāng)今數(shù)字化時(shí)代，數(shù)據(jù)量呈爆炸式增長(zhǎng)，對(duì)于應(yīng)用程序而言，保障數(shù)據(jù)的高可用性和高性能變得至關(guān)重要。在眾多的解決方案中，Redis憑借其豐富的特性脫穎而出，而主從復(fù)制便是其中一項(xiàng)關(guān)鍵技術(shù)。

想象一下，一個(gè)大型電商平臺(tái)在促銷活動(dòng)期間，海量的用戶請(qǐng)求如潮水般涌來(lái)。此時(shí)，單一的Redis實(shí)例很難應(yīng)對(duì)如此巨大的流量壓力，而且一旦出現(xiàn)故障，整個(gè)系統(tǒng)可能會(huì)陷入癱瘓。Redis主從復(fù)制機(jī)制就如同為系統(tǒng)搭建了一道堅(jiān)固的防線，通過復(fù)制主節(jié)點(diǎn)的數(shù)據(jù)到多個(gè)從節(jié)點(diǎn)，不僅提升了系統(tǒng)的讀取性能，還增強(qiáng)了數(shù)據(jù)的可靠性。

Redis主從復(fù)制是如何巧妙地實(shí)現(xiàn)數(shù)據(jù)同步的？在實(shí)際應(yīng)用中又該如何進(jìn)行配置和管理？不同節(jié)點(diǎn)之間的角色是如何協(xié)同工作的？接下來(lái)，就讓我們一同深入Redis主從復(fù)制的世界，揭開其神秘的面紗，探尋其中的奧秘。

一、詳解Redis主從復(fù)制

1. 主從復(fù)制的基本概念

主從復(fù)制就是將主節(jié)點(diǎn)(master)的數(shù)據(jù)復(fù)制到從節(jié)點(diǎn)(slave)，讓多個(gè)節(jié)點(diǎn)承載用戶的請(qǐng)求：

主從復(fù)制具備以下幾個(gè)特點(diǎn)：

• 數(shù)據(jù)冗余:主節(jié)點(diǎn)的數(shù)據(jù)都會(huì)同步到從節(jié)點(diǎn)上，所以多個(gè)節(jié)點(diǎn)都會(huì)有相同數(shù)據(jù)，從而實(shí)現(xiàn)數(shù)據(jù)冗余。
• 故障恢復(fù):主節(jié)點(diǎn)出現(xiàn)故障后，從節(jié)點(diǎn)可以繼續(xù)承載用戶的請(qǐng)求，做到服務(wù)上的冗余。
• 負(fù)載均衡:主從復(fù)制機(jī)制實(shí)現(xiàn)主節(jié)點(diǎn)接收用戶寫請(qǐng)求，從節(jié)點(diǎn)承載用戶讀請(qǐng)求，對(duì)于讀多寫少的場(chǎng)景，這種機(jī)制可以大大提高redis的并發(fā)量。
• 高負(fù)載:主從復(fù)制+哨兵機(jī)制可以實(shí)現(xiàn)高負(fù)載，這點(diǎn)后文會(huì)介紹到。

2. 主從復(fù)制使用示例

首先我們先來(lái)介紹一下一主二從，即搭建一個(gè)主節(jié)點(diǎn)和兩個(gè)從節(jié)點(diǎn)，主節(jié)點(diǎn)負(fù)責(zé)寫入請(qǐng)求，從節(jié)點(diǎn)同步數(shù)據(jù)對(duì)外提供數(shù)據(jù)讀服務(wù)：

創(chuàng)建3個(gè)redis配置文件，以筆者為例，名字分別為redis6379.conf、redis6380.conf、redis6381.conf，同時(shí)我們將6379這個(gè)端口號(hào)的redis作為主節(jié)點(diǎn)，配置內(nèi)容如下:

# 引入redis基本配置，注意這個(gè)配置只支持RDB
include /root/redis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
# 設(shè)置RDB文件名
dbfilename dump6379.rdb

從節(jié)點(diǎn)以6380，配置如下：

# 引入redis基本配置，注意這個(gè)配置只支持RDB
include /root/redis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
# 作為6379的主節(jié)點(diǎn)
slaveof 127.0.0.1 6379

分別啟動(dòng)這幾個(gè)redis：

redis-server /root/redis/conf/redis6379.conf
 redis-server /root/redis/conf/redis6380.conf
 redis-server /root/redis/conf/redis6381.conf

完成配置后，我們就可以開始測(cè)試了，首先對(duì)清空主節(jié)點(diǎn)數(shù)據(jù)，并設(shè)置一些值進(jìn)去：

127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> set master_key value
OK
127.0.0.1:6379>

我們看看從節(jié)點(diǎn)是否存在這個(gè)key值，可以發(fā)現(xiàn)這個(gè)值確實(shí)存在。

# 可以看到主節(jié)點(diǎn)的key來(lái)了
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli -p 6380
127.0.0.1:6380> keys *
1) "master_key"
127.0.0.1:6380>

再使用命令看看6380，發(fā)現(xiàn)其角色也確實(shí)是從節(jié)點(diǎn)：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
.... 略

3. 演示主從復(fù)制運(yùn)行時(shí)異常

從節(jié)點(diǎn)掛掉，在啟動(dòng)，數(shù)據(jù)不會(huì)丟失，照樣是主節(jié)點(diǎn)的從節(jié)點(diǎn)，這個(gè)點(diǎn)我們也可以拿個(gè)例子來(lái)展示一下,首先我們可以將從節(jié)點(diǎn)掛掉:

# 強(qiáng)制掛掉從節(jié)點(diǎn)
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli -p 6380
127.0.0.1:6380> SHUTDOWN
not connected>

清空數(shù)據(jù)主節(jié)點(diǎn)設(shè)置一些新數(shù)據(jù)，再次啟動(dòng)從節(jié)點(diǎn)，可以發(fā)現(xiàn)它還是從節(jié)點(diǎn)的角色：

# 啟動(dòng) 發(fā)現(xiàn)數(shù)據(jù)都在，并且角色也是slave
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/conf/redis6380.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
.....略

主節(jié)點(diǎn)掛了，從節(jié)點(diǎn)仍然是從節(jié)點(diǎn)，主節(jié)點(diǎn)恢復(fù)后仍然是主節(jié)點(diǎn)。

這個(gè)例子，首先我們也是需要將主節(jié)點(diǎn)掛掉:

# 強(qiáng)制掛掉主節(jié)點(diǎn)
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> SHUTDOWN
not connected>

完成后再次將主節(jié)點(diǎn)啟動(dòng)，然后進(jìn)行操作，發(fā)現(xiàn)角色仍然是master，而且進(jìn)行各種set操作80這個(gè)從節(jié)點(diǎn)也會(huì)同步復(fù)制。

# 再次啟動(dòng)主節(jié)點(diǎn)，發(fā)現(xiàn)key都在并且角色仍然是master，設(shè)置一個(gè)k2值
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/conf/redis6379.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> set key2 v2
OK
127.0.0.1:6379>

# 從節(jié)點(diǎn)仍然可以收到，說(shuō)明主節(jié)點(diǎn)仍然是6379
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli -p 6380
127.0.0.1:6380> keys *
1) "key2"
2) "master_key"
127.0.0.1:6380>

4. 主從復(fù)制下的薪火相傳

如果大量主節(jié)點(diǎn)配合大量從節(jié)點(diǎn)，會(huì)導(dǎo)致主節(jié)點(diǎn)會(huì)導(dǎo)致數(shù)據(jù)同步時(shí)長(zhǎng)增加，所以我們可以將部分從節(jié)點(diǎn)掛到某部分從節(jié)點(diǎn)下面，以此類推，作為從節(jié)點(diǎn)的從節(jié)點(diǎn)：

以筆者本次示例為例，我們將81作為80的從節(jié)點(diǎn)：

# 為了方便，筆者使用命令的形式，讀者也可以使用conf文件配置
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
127.0.0.1:6381>

再次查看80節(jié)點(diǎn)，可以看到slave0:ip=127.0.0.1,port=6381,state=online,offset=810,lag=1，由此可知從節(jié)點(diǎn)的從節(jié)點(diǎn)配置完成：

[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
# 6381變?yōu)樗膹墓?jié)點(diǎn)
slave0:ip=127.0.0.1,port=6381,state=online,offset=810,lag=1

5. 反客為主

對(duì)著從節(jié)點(diǎn)鍵入下面在這段命令，即直接讓從節(jié)點(diǎn)停止復(fù)制并直接晉升為主節(jié)點(diǎn)：

slaveof  no one

二、、主從復(fù)制進(jìn)階知識(shí)點(diǎn)

1. 主從復(fù)制的原理

主從復(fù)制有兩種模式，我就先來(lái)說(shuō)說(shuō)全量復(fù)制吧，如下圖,整體步驟為：

• 從節(jié)點(diǎn)向主節(jié)點(diǎn)發(fā)送同步請(qǐng)求，因?yàn)椴恢乐鲙?kù)的runID，并且不知道同步的偏移量是多少，所以參數(shù)分別為? -1,同步請(qǐng)求的指令為psync
• 主庫(kù)執(zhí)行bgsave指令生成rdb指令，將數(shù)據(jù)發(fā)送給從庫(kù)，從庫(kù)為了保證數(shù)據(jù)一致性，會(huì)將數(shù)據(jù)清空，然后加載rdb文件，完成數(shù)據(jù)同步。在此期間，主庫(kù)收到的新數(shù)據(jù)都會(huì)被存入replication buffer中。
• 主庫(kù)會(huì)將replication buffer發(fā)送給從庫(kù)，完成最新數(shù)據(jù)的同步。

從 Redis 2.8 開始，因?yàn)榫W(wǎng)絡(luò)斷開導(dǎo)致數(shù)據(jù)同步中斷的情況，會(huì)采用增量復(fù)制的方式完成數(shù)據(jù)補(bǔ)充。

需要了解的是，當(dāng)主從同步過程中因?yàn)榫W(wǎng)絡(luò)等問題發(fā)生中斷，repl_backlog_buffer會(huì)保存兩者之間差異的數(shù)據(jù)，如果從庫(kù)長(zhǎng)時(shí)間沒有恢復(fù)，很可能出現(xiàn)該環(huán)形緩沖區(qū)數(shù)據(jù)被覆蓋進(jìn)而出現(xiàn)增量復(fù)制失敗，只能通過全量復(fù)制的方式實(shí)現(xiàn)數(shù)據(jù)同步。

需要一個(gè)概念replication buffer，這個(gè)緩沖區(qū)用于存放用戶寫入的新指令，完成全量復(fù)制之后的數(shù)據(jù)都是通過這個(gè)buffer的數(shù)據(jù)傳輸實(shí)現(xiàn)數(shù)據(jù)增量同步。

2. 主服務(wù)器不進(jìn)行持久化復(fù)制存在什么問題

設(shè)想下面這樣一個(gè)場(chǎng)景，主節(jié)點(diǎn)沒有使用RDB持久化，數(shù)據(jù)沒有持久化到磁盤，在此期間主節(jié)點(diǎn)掛掉又立刻恢復(fù)了，此時(shí)主節(jié)點(diǎn)所有數(shù)據(jù)都丟失了，從節(jié)點(diǎn)很可能會(huì)因此清空原本數(shù)據(jù)進(jìn)而導(dǎo)致數(shù)據(jù)丟失。

3. 為什么主從復(fù)制使用RDB而不是AOF

RDB是二進(jìn)制且壓縮過的文件，傳輸速度以及加載速度都遠(yuǎn)遠(yuǎn)快速AOF。且AOF存的都是指令非常耗費(fèi)磁盤空間，加載時(shí)都是重放每個(gè)寫命令，非常耗時(shí)。需要注意的是RDB是按照時(shí)間間隔進(jìn)行持久化，對(duì)于數(shù)據(jù)不敏感的場(chǎng)景我們還是建議使用RDB。

4. 什么是無(wú)磁盤復(fù)制模式

數(shù)據(jù)同步不經(jīng)過主進(jìn)程以及硬盤，直接創(chuàng)建一個(gè)新進(jìn)程dump RDB數(shù)據(jù)到從節(jié)點(diǎn)。對(duì)于磁盤性能較差的服務(wù)器可以使用這種方式。配置參數(shù)為:

repl-diskless-sync no # 決定是否開啟無(wú)磁盤復(fù)制模式
repl-diskless-sync-delay 5 # 決定同步的時(shí)間間隔

5. 為什么會(huì)有從庫(kù)的從庫(kù)設(shè)計(jì)

由上可知，主庫(kù)執(zhí)行數(shù)據(jù)同步時(shí)，需要執(zhí)行如下步驟：

• 生成rdb文件。
• 傳輸數(shù)據(jù)給從庫(kù)。

為避免主庫(kù)因?yàn)轭l繁為大量從庫(kù)做同步導(dǎo)致性能下降，于是我們才引入從庫(kù)的從庫(kù)這一設(shè)計(jì)方案分散同步壓力：

6. 讀寫分離及其中的問題

大抵需要考慮以下這些問題:

• 延遲與不一致問題:如果對(duì)數(shù)據(jù)一致性容忍度較低，網(wǎng)絡(luò)延遲導(dǎo)致數(shù)據(jù)不一致問題只能通過提高網(wǎng)絡(luò)帶寬，或者通知應(yīng)用不在通過該節(jié)點(diǎn)獲取數(shù)據(jù)
• 數(shù)據(jù)過期問題,從節(jié)點(diǎn)很可能在某一時(shí)刻某些過期數(shù)據(jù)被讀取到了，這就會(huì)給用戶造成很詭異的場(chǎng)景。
• 故障切換問題

7. 如果在網(wǎng)絡(luò)斷開期間，repl_backlog_buffer 環(huán)形緩沖區(qū)寫滿之后，是進(jìn)行全量還是增量復(fù)制

針對(duì)這個(gè)問題我們必須要了解repl_backlog_buffer是什么，它是redis主從同步時(shí)master的一個(gè)環(huán)形緩沖區(qū)，在master節(jié)點(diǎn)同步指令給slave時(shí)，這個(gè)緩沖區(qū)也會(huì)臨時(shí)緩沖這部分?jǐn)?shù)據(jù)以保證slave斷線重連后的數(shù)據(jù)補(bǔ)償，針對(duì)該問題，我們需要分兩種情況說(shuō)：

• 若主庫(kù)的repl_backlog_buffer的slave_repl_offset已經(jīng)被覆蓋，那么同步就需要全量復(fù)制了
• 從庫(kù)會(huì)通過psync命令把自己記錄的slave_repl_offset發(fā)給主庫(kù)，主庫(kù)根據(jù)復(fù)制進(jìn)度決定是增量復(fù)制還是全量復(fù)制。

8. 1主2從redis架構(gòu)如何抗住1000w的qps

結(jié)合redis官方給出壓測(cè)報(bào)告來(lái)看，redis的qps基本在8w~15w這個(gè)區(qū)間，所以如果需要應(yīng)對(duì)1000w的qps我們就需要考慮水平復(fù)制數(shù)據(jù)并拓展，按照壓測(cè)的情況并結(jié)合只需要抗住qps的需求，我們可以得出第一個(gè)方案——通過薪火相傳的架構(gòu)來(lái)保證數(shù)據(jù)同步。

按照單機(jī)10w的qps來(lái)?yè)Q算，我們可以通過100個(gè)redis節(jié)點(diǎn)搭建一個(gè)薪火相傳的架構(gòu)抗住并發(fā)壓力：

當(dāng)然考慮到100個(gè)節(jié)點(diǎn)的成本可能不切實(shí)際，所以我們也可以采取另一套相對(duì)折中的方案，結(jié)合服務(wù)器資源部署一套redis主從架構(gòu)+哨兵架構(gòu)保證高可用，然后各個(gè)服務(wù)模塊基于本地內(nèi)存到redis中同步熱點(diǎn)數(shù)據(jù)，讓應(yīng)用直接對(duì)外提供緩存數(shù)據(jù)檢索，由此節(jié)約了資源成本還間接的減小的接口響應(yīng)的RT：