對(duì)于大型企業(yè)來(lái)說(shuō)，一臺(tái) Redis 實(shí)例要保證可用性，往往會(huì)配置主從庫(kù)。這一點(diǎn)上其實(shí)和 MySQL 是一樣的，我們絕大部分的業(yè)務(wù)需求通常的情況都是讀多寫少。在這種情況下，合理的分?jǐn)傋x庫(kù)請(qǐng)求，就可以大大加強(qiáng)請(qǐng)求的響應(yīng)速度。對(duì)比 MySQL 來(lái)說(shuō)，Redis 的主從復(fù)制簡(jiǎn)單的沒(méi)朋友。
對(duì)于我們測(cè)試學(xué)習(xí)來(lái)說(shuō)，一般不會(huì)去建立多個(gè)虛擬機(jī)或者 Docker ，更不可能去買多臺(tái)真正的服務(wù)器來(lái)練習(xí)。大家一般都是多開(kāi)幾個(gè)實(shí)例，只要端口號(hào)不重復(fù)就行了。因此，我們需要多建兩個(gè)配置文件，區(qū)分開(kāi)端口號(hào)。
// vim redis_80.conf
include /usr/local/etc/redis.conf
port 6380
pidfile "/var/run/redis_6380.pid"
dbfilename "dump6380.rdb"
默認(rèn)的 Redis 端口號(hào)是 6379 ，為了測(cè)試方便，我們就新建兩個(gè)文件，一個(gè)用 6380 ，一個(gè)用 6381 。配置文件可以直接 include 默認(rèn)的那個(gè)主配置文件，然后覆蓋寫上新的端口號(hào)就可以了。另外需要注意的是，pidfile 和 dbfilename 也要換個(gè)名字，要不就會(huì)共用 6379 的。6381 的配置文件也是類似的，這里就不粘出來(lái)了。然后我們啟動(dòng) 6380 和 6381 。
// 服務(wù)端 6380
redis-server redis_80.conf
// 服務(wù)端 6381
redis-server redis_81.conf
如果你不想在控制臺(tái)看到啟動(dòng)情況，或者說(shuō)想讓實(shí)例在后臺(tái)運(yùn)行的話，可以再加上下面這個(gè)配置。
// 配置文件
daemonize yes
然后使用客戶端進(jìn)入 6380 和 6381 ，直接運(yùn)行 SLAVEOF <host> <port> 命令，其中 host 指的是主庫(kù)的地址，port 指的是主庫(kù)的端口號(hào)。
// 客戶端 6380
? redis-cli -p 6380
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
// 客戶端 6381
? redis-cli -p 6381
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
OK
好了，6380 和 6381 就是 6379 的兩臺(tái)從庫(kù)了。是不是很簡(jiǎn)單，我們?nèi)ヲ?yàn)證一下。
// 客戶端 6379
127.0.0.1:6379> INFO Replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=252,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=252,lag=1
………………
127.0.0.1:6379> role
1) "master"
2) (integer) 1313
3) 1) 1) "127.0.0.1"
2) "6380"
3) "1313"
2) 1) "127.0.0.1"
2) "6381"
3) "1313"
在 6379 上，使用 INFO Replication 就可以看到當(dāng)前的角色是 master ，有兩臺(tái)從庫(kù)，它們的狀態(tài)信息也都能看到。另外還有一個(gè)命令就是 role ，它也能看到當(dāng)前的主從狀態(tài)信息。第一行是本機(jī)的角色，下面是從庫(kù)的情況。同樣的，在從庫(kù)上也能看到相關(guān)的信息。
// 客戶端 6380
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:4
master_sync_in_progress:0
slave_read_repl_offset:378
slave_repl_offset:378
slave_priority:100
slave_read_only:1
………………
127.0.0.1:6380> role
1) "slave"
2) "127.0.0.1"
3) (integer) 6379
4) "connected"
5) (integer) 1341
好了，現(xiàn)在試試看主從之間有沒(méi)有真正的實(shí)現(xiàn)復(fù)制吧。
// 客戶端 6379
? redis-cli -p 6379
127.0.0.1:6379> set a 111
OK
// 客戶端 6380
? redis-cli -p 6380
127.0.0.1:6380> get a
"111"
可以看到，我們?cè)?6379 添加了一個(gè) a 的數(shù)據(jù)，然后到 6380 可以 GET 到這條數(shù)據(jù)。嗯，目前來(lái)看主從配置是完全沒(méi)問(wèn)題啦。
要說(shuō)明的是，SLAVEOF 命令也可以配置到配置文件中，這樣實(shí)例一啟動(dòng)就直接會(huì)進(jìn)行主從連接。
當(dāng)主庫(kù)和從庫(kù)建立起連接后，主庫(kù)會(huì)發(fā)送命令流來(lái)保持對(duì)從庫(kù)的更新，包括客戶端的寫入、key的過(guò)期等。如果從庫(kù)斷開(kāi)連接，過(guò)一段時(shí)間又重新連接之后，會(huì)進(jìn)行部分重同步，可能會(huì)丟失部分命令。如果無(wú)法進(jìn)行部分重同步的話，從庫(kù)會(huì)請(qǐng)求進(jìn)行全量同步，也就是主庫(kù)會(huì)把 rdb 整個(gè)發(fā)送給從庫(kù)。
整個(gè)同步復(fù)制的過(guò)程都是走的異步復(fù)制，具有低延遲和高性能的特點(diǎn)。從庫(kù)和從庫(kù)之間也可以建立主從關(guān)系，從而形成一個(gè)樹(shù)狀的同步結(jié)構(gòu)，當(dāng)最頂上的主庫(kù)掛了的時(shí)候，可以馬上選擇一臺(tái)擁有從庫(kù)的從庫(kù)來(lái)切換成主庫(kù)，從而保證服務(wù)提供的可用性。
如果想要高性能，我們其實(shí)可以這樣配置，那就是主庫(kù)不做持久化，而在從庫(kù)中選一臺(tái)出來(lái)做持久化。雖然這樣做可以獲取到很高的性能，但是，假如主庫(kù)掛了，那么當(dāng)它重啟的時(shí)候，會(huì)是一個(gè)空的數(shù)據(jù)庫(kù)。這樣的空數(shù)據(jù)庫(kù)也會(huì)同步給從庫(kù)，從而導(dǎo)致所有數(shù)據(jù)全部被清空，這一點(diǎn)是需要注意的。特別是配置了一些自動(dòng)重啟實(shí)例的工具的情況下，非常危險(xiǎn)。
因此，還是更建議主從都開(kāi)啟持久化，或者使用哨兵機(jī)制以及分布式的方式來(lái)進(jìn)行部署，這兩塊我們后面的文章馬上就會(huì)學(xué)習(xí)到哦。
如果主庫(kù)有密碼，我們可以通過(guò) masterauth <password> 這個(gè)命令或者直接在配置文件中寫上，來(lái)設(shè)置從庫(kù)連接到主庫(kù)之后使用的密碼。
SLAVEOF 命令已經(jīng)是過(guò)時(shí)的命令了，在 Redis5 之后，更推薦使用的是 REPLICAOF <masterip> <masterport> ，參數(shù)和使用方式與 SLAVEOF 是一樣的。在現(xiàn)在的版本中，默認(rèn)的配置文件中也只能搜到 REPLICAOF ，搜不到 SLAVEOF ，但是這個(gè)命令還是可以正常使用的。大家將來(lái)應(yīng)用的時(shí)候，如果版本是在 Redis5 及以上的話，還是盡量使用新的命令哦。
Redis 的從庫(kù)不會(huì)主動(dòng)清理過(guò)期的 Key ，這是為啥呢？因?yàn)橐?tīng)老大的嘛。當(dāng)主庫(kù)的 Key 過(guò)期后，主庫(kù)會(huì)發(fā)送一個(gè) DEL 給從庫(kù)，從而實(shí)現(xiàn)過(guò)期 Key 的刪除。
但是，主從多少會(huì)有延遲的嘛，所以從庫(kù)也有自己的一個(gè)邏輯時(shí)鐘用以報(bào)告不違反數(shù)據(jù)庫(kù)一致性的讀操作中存在的 Key 。也就是說(shuō)，從庫(kù)雖然不會(huì)主動(dòng)過(guò)期，但也會(huì)在自己的計(jì)時(shí)中標(biāo)注當(dāng)前這個(gè) Key 是否已經(jīng)過(guò)期，只不過(guò)，它不會(huì)真的刪除這個(gè) Key ，而是要等待主庫(kù)的命令到達(dá)。如果客戶端請(qǐng)求，它將返回一個(gè)空值。在 Redis3.2 之前的版本中，從庫(kù)沒(méi)有自己的邏輯時(shí)鐘，這是一個(gè)大問(wèn)題，所以老版本的小伙伴一定要注意（這個(gè)現(xiàn)在應(yīng)該很少了吧）。
因此，要注意主從庫(kù)，特別是不在一臺(tái)服務(wù)器上的主從庫(kù)之間的時(shí)鐘同步性。
另外一種情況就是沒(méi)有設(shè)置過(guò)期時(shí)間的，就是主庫(kù)主動(dòng)刪除的 Key 。只要是有同步，那么必然就會(huì)有延遲，因此，盡量將主從實(shí)例的主機(jī)部署在同一個(gè)機(jī)房，盡量的減少同步延遲就是最重要的步驟了，這一塊不僅是 Redis ，任何牽涉到主從復(fù)制這種機(jī)制的應(yīng)用都會(huì)有這個(gè)問(wèn)題，可以考慮應(yīng)用層面上的代碼解決方案，更深層次上就是整體架構(gòu)設(shè)計(jì)方面的問(wèn)題了。這一塊咱的水平不夠，也說(shuō)不出個(gè)所以然來(lái)，更重要的是，沒(méi)經(jīng)歷過(guò)啊，中小型公司能將一臺(tái) Redis 實(shí)例的極限性能能發(fā)揮出來(lái)的都少之又少，所以只能將來(lái)我們學(xué)習(xí)到相關(guān)架構(gòu)實(shí)踐的時(shí)候再來(lái)說(shuō)吧！
另外配置文件中的 repl-disable-tcp-nodelay 參數(shù)如果選擇 no 的話，可以降低主從延遲，但是會(huì)加大帶寬消耗，如果在一個(gè)機(jī)房是可以考慮關(guān)閉這個(gè)參數(shù)的，畢竟內(nèi)網(wǎng)基本是不收費(fèi)的，而且?guī)掃€大。
第一臺(tái)主庫(kù)會(huì)有一個(gè) replication ID ，這是一個(gè)隨機(jī)字符串，在 INFO 中可以看到。
127.0.0.1:6379> info replication
………………
master_replid:1cf72f79da111329945c43855616ca5cf4b43f1a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
………………
同時(shí)也有一個(gè)偏移量 offset 。
主庫(kù)將自己產(chǎn)生的復(fù)制流發(fā)送給從庫(kù)的時(shí)候，發(fā)送多少個(gè)字節(jié)的數(shù)據(jù)，自身的偏移量就會(huì)增加多少，目的就是當(dāng)有新的操作修改數(shù)據(jù)時(shí)，可以以此更新從庫(kù)的狀態(tài)。這個(gè)其實(shí)就和 MySQL 主從中的 binlog 日志一樣，在配置主庫(kù)的時(shí)候，我們也會(huì)記錄當(dāng)前的一個(gè)偏移量，然后等待從庫(kù)同步到與主庫(kù)相同的狀態(tài)時(shí)，才開(kāi)放主庫(kù)的寫操作。一般也會(huì)通過(guò)偏移量來(lái)確定主從之間是否產(chǎn)生延遲。
接著，從庫(kù)通過(guò) PSYNC 命令發(fā)送請(qǐng)求并獲得 replication ID 和 offset ，開(kāi)始比較自己的同步情況，然后進(jìn)行數(shù)據(jù)同步。這一塊我們可以通過(guò) SYNC 命令看到。
127.0.0.1:6380> SYNC
Entering replica output mode... (press Ctrl-C to quit)
SYNC with master, discarding 14838 bytes of bulk transfer...
SYNC done. Logging commands from master.
"set","b","222"
"ping"
開(kāi)啟 SYNC 命令之后，從庫(kù)會(huì)不停地發(fā)送 PING 命令，這時(shí)你可以在主庫(kù)上隨便進(jìn)行一個(gè)操作，然后回到從庫(kù)，就可以看到 SYNC 也輸出了從主庫(kù)上獲得的命令信息。
默認(rèn)情況下，Redis 中的從庫(kù)是只讀的，就像下面這樣。
// 客戶端 6380
127.0.0.1:6380> set a 123
(error) READONLY You can't write against a read only replica.
這是因?yàn)槟J(rèn)情況下，在配置文件中，有這樣一個(gè)配置 slave-read-only yes ，它的意思很明顯，就是從庫(kù)只能讀。我們可以修改配置文件，也可以動(dòng)態(tài)修改它。
127.0.0.1:6380> config set slave-read-only no
OK
127.0.0.1:6380> set a 123
OK
127.0.0.1:6380> get a
"123"
// 客戶端 6379
? ~ redis-cli -p 6379
127.0.0.1:6379> get a
"111"
127.0.0.1:6379> set a 456
OK
// 客戶端 6380
? ~ redis-cli -p 6380
127.0.0.1:6380> get a
"456"
從上面的測(cè)試情況可以看出，將 slave-read-only 設(shè)置為 no 之后，從庫(kù)也可以寫數(shù)據(jù)了。但是主庫(kù)一旦修改了這條數(shù)據(jù)，那么從庫(kù)還會(huì)跟著主庫(kù)變。
說(shuō)實(shí)話，這一塊不要有太大別的想法，從庫(kù)做好自己的事就好了，要是從庫(kù)能夠任意修改，那么數(shù)據(jù)一致性就會(huì)出現(xiàn)大問(wèn)題了。
除了提供讀庫(kù)的分?jǐn)偭髁柯氊?zé)之外，主從復(fù)制還有一個(gè)好處就是可以快速地進(jìn)行主從切換，從而提高整個(gè) Redis 實(shí)例的可用性，也就是我們常說(shuō)的 主備架構(gòu) 。將從機(jī)或者多個(gè)從機(jī)的某一臺(tái)從機(jī)當(dāng)做備份機(jī)，如果主機(jī)崩掉了，可以馬上用備份機(jī)頂上。今天我們先來(lái)看看怎么手動(dòng)實(shí)現(xiàn)主備切換。
// 關(guān)閉6379
? brew services stop redis
Stopping `redis`... (might take a while)
==> Successfully stopped `redis` (label: homebrew.mxcl.redis)
// 查看6380狀態(tài)
? redis-cli -p 6380
127.0.0.1:6380> role
1) "slave"
2) "127.0.0.1"
3) (integer) 6379
4) "connect"
5) (integer) -1
// 6380服務(wù)端日志
48041:S 22 Jun 2022 09:58:32.532 * Connecting to MASTER 127.0.0.1:6379
48041:S 22 Jun 2022 09:58:32.532 * MASTER <-> REPLICA sync started
48041:S 22 Jun 2022 09:58:32.532 # Error condition on socket for SYNC: Connection refused
在上面的操作中，當(dāng)我們關(guān)閉了 6379 ，也就是主庫(kù)之后，從庫(kù)的狀態(tài)中，connect 變成了 -1 ，同時(shí)，服務(wù)實(shí)例輸出的日志也出現(xiàn)了報(bào)錯(cuò)信息，表示當(dāng)前的連接不可用。接下來(lái)，我們就趕緊把 6380 升級(jí)成主庫(kù)吧。
// 6380
127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> role
1) "master"
2) (integer) 2826
3) (empty array)
使用命令 SLAVEOF no one 就可以將當(dāng)前的從庫(kù)轉(zhuǎn)回一臺(tái)默認(rèn)的普通實(shí)例，這時(shí)默認(rèn)它就是主庫(kù)，不過(guò)是一臺(tái)還沒(méi)有從庫(kù)的主庫(kù)而已。接下來(lái)，把 6381 轉(zhuǎn)換成 6380 的從庫(kù)。
// 6381
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
127.0.0.1:6381> role
1) "slave"
2) "127.0.0.1"
3) (integer) 6380
4) "connected"
5) (integer) 2826
這個(gè)就不多說(shuō)了，當(dāng) 6379 恢復(fù)之后，我們?cè)僮?6379 成為 6380 的主庫(kù)就好了。
應(yīng)用程序上呢？這個(gè)真沒(méi)辦法，我們需要去修改連接信息，讓程序去連接新的主庫(kù)，從庫(kù)的配置也要修改。是不是很麻煩？別急，下一篇我們就來(lái)學(xué)習(xí)自動(dòng)切換的哨兵機(jī)制。
今天的內(nèi)容很簡(jiǎn)單，因?yàn)榇_實(shí) Redis 在主從配置這一塊非常方便。而且因?yàn)?Redis 本身就非常快，所以大部分情況下我們不需要像 MySQL 那樣在新開(kāi)從庫(kù)的時(shí)候要等從庫(kù)同步很久才能使用。它也是可以邊提供寫入服務(wù)，邊進(jìn)行從庫(kù)同步的，如果確實(shí)主庫(kù)的數(shù)據(jù)量非常大，需要進(jìn)行全量同步從庫(kù)的話，可以在主庫(kù)使用 WAIT 命令進(jìn)行鎖寫等待。
好了，下一篇我們就要學(xué)習(xí)激動(dòng)人心的主從高可用功能：哨兵機(jī)制 。別掉隊(duì)哦，進(jìn)階系列的內(nèi)容不多了，但后面可是篇篇精彩。
參考文檔：
https://redis.io/docs/manual/replication/
聯(lián)系客服
