Redis主從架構(gòu)的建立方式有哪些

這篇文章主要介紹了Redis主從架構(gòu)的建立方式有哪些的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇Redis主從架構(gòu)的建立方式有哪些文章都會(huì)有所收獲，下面我們一起來看看吧。

主從環(huán)境搭建

redis 的實(shí)例在默認(rèn)的情況下都是主節(jié)點(diǎn)，所以我們需要修改一些配置來搭建主從架構(gòu)，redis 的主從架構(gòu)搭建還是比較簡(jiǎn)單的，redis  提供了三種方式來搭建主從架構(gòu)，在后面我們將就介紹，在介紹之前我們要先了解主從架構(gòu)的特性：在主從架構(gòu)中有一個(gè)主節(jié)點(diǎn)(master)和最少一個(gè)從節(jié)點(diǎn)(slave)，并且數(shù)據(jù)復(fù)制是單向的，只能從主節(jié)點(diǎn)復(fù)制到從節(jié)點(diǎn)，不能由從節(jié)點(diǎn)到主節(jié)點(diǎn)。

主從架構(gòu)的建立方式

主從架構(gòu)的建立有以下三種方式：

• 在 Redis.conf 配置文件中加入 slaveof {masterHost} {masterPort} 命令，隨 Redis 實(shí)例的啟動(dòng)生效

• 在 redis-server 啟動(dòng)命令后加入 --slaveof {masterHost} {masterPort} 參數(shù)

• 在 redis-cli 交互窗口下直接使用命令：slaveof {masterHost} {masterPort}

上面三種方式都可以搭建 Redis 主從架構(gòu)，我們以第一種方式來演示，其他兩種方式自行嘗試，由于是演示，所以就在本地啟動(dòng)兩個(gè) Redis  實(shí)例，并不在多臺(tái)機(jī)器上啟動(dòng) redis 的實(shí)例了，我們準(zhǔn)備一個(gè)端口 6379 的主節(jié)點(diǎn)實(shí)例，準(zhǔn)備一個(gè)端口 6480 從節(jié)點(diǎn)的實(shí)例，端口 6480 的 redis  實(shí)例配置文件取名為 6480.conf 并且在里面添加 slaveof 語句，在配置文件最后加入如下一條語句。

slaveof 127.0.0.1 6379

分別啟動(dòng)兩個(gè) redis 實(shí)例，啟動(dòng)之后他們會(huì)自動(dòng)建立主從關(guān)系，關(guān)于這背后的原理，我們后面在詳細(xì)的聊一聊，先來驗(yàn)證一下我們的主從架構(gòu)是否搭建成功，我們先在  6379 master 節(jié)點(diǎn)上新增一條數(shù)據(jù)：

master 節(jié)點(diǎn)新增數(shù)據(jù)

然后再 6480 slave 節(jié)點(diǎn)上獲取該數(shù)據(jù)：

slave 節(jié)點(diǎn)獲取數(shù)據(jù)

可以看出我們?cè)?slave 節(jié)點(diǎn)上已經(jīng)成功的獲取到了在 master 節(jié)點(diǎn)新增的值，說明主從架構(gòu)已經(jīng)搭建成功了，我們使用 info replication  命令來查看兩個(gè)節(jié)點(diǎn)的信息，先來看看主節(jié)點(diǎn)的信息。

master info replication

可以看出 6379 端口的實(shí)例 role 為 master，有一個(gè)正在連接的實(shí)例，還有其他運(yùn)行的信息，我們?cè)賮砜纯?6480 端口的 redis  實(shí)例信息。

slave info replication

可以看出兩個(gè)節(jié)點(diǎn)之間相互記錄著對(duì)象的信息，這些信息在數(shù)據(jù)復(fù)制時(shí)候?qū)?huì)用到。在這里有一點(diǎn)需要說明一下，默認(rèn)情況下 slave  節(jié)點(diǎn)是只讀的，并不支持寫入，也不建議開啟寫入，我們可以驗(yàn)證一下，在 6480 實(shí)例上寫入一條數(shù)據(jù)。

127.0.0.1:6480> set x 3 (error) READONLY You can't write against a read only replica. 127.0.0.1:6480>

提示只讀，并不支持寫入操作，當(dāng)然我們也可以修改該配置，在配置文件中 replica-read-only yes  配置項(xiàng)就是用來控制從服務(wù)器只讀的，為什么只能只讀?因?yàn)槲覀冎缽?fù)制是單向的，數(shù)據(jù)只能由 master 到 slave 節(jié)點(diǎn)，如果在 salve  節(jié)點(diǎn)上開啟寫入的話，那么修改了 slave 節(jié)點(diǎn)的數(shù)據(jù)， master 節(jié)點(diǎn)是感知不到的，slave 節(jié)點(diǎn)的數(shù)據(jù)并不能復(fù)制到 master  節(jié)點(diǎn)上，這樣就會(huì)造成數(shù)據(jù)不一致的情況，所以建議 slave 節(jié)點(diǎn)只讀。

主從架構(gòu)的斷開

主從架構(gòu)的斷開同樣是 slaveof 命令，在從節(jié)點(diǎn)上執(zhí)行 slaveof no one 命令就可以與主節(jié)點(diǎn)斷開追隨關(guān)系，我們?cè)?6480  節(jié)點(diǎn)上執(zhí)行 slaveof no one 命令。

127.0.0.1:6480> slaveof no one OK 127.0.0.1:6480> info replication # Replication role:master connected_slaves:0 master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27 master_repl_offset:4367 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4367 127.0.0.1:6480>

執(zhí)行完 slaveof no one 命令之后，6480 節(jié)點(diǎn)的角色立馬恢復(fù)成了 master ，我們?cè)賮砜纯磿r(shí)候還和 6379 實(shí)例連接在一起，我們?cè)? 6379 節(jié)點(diǎn)上新增一個(gè) key-value。

127.0.0.1:6379> set y 3 OK

在 6480 節(jié)點(diǎn)上 get y

127.0.0.1:6480> get y (nil) 127.0.0.1:6480>

在 6480 節(jié)點(diǎn)上獲取不到 y ，因?yàn)?6480 節(jié)點(diǎn)已經(jīng)跟 6379 節(jié)點(diǎn)斷開的聯(lián)系，不存在主從關(guān)系了，slaveof  命令不僅能夠斷開連接，還能切換主服務(wù)器，使用命令為 slaveof {newMasterIp} {newMasterPort}，我們讓 6379 成為 6480  的從節(jié)點(diǎn)， 在 6379 節(jié)點(diǎn)上執(zhí)行 slaveof 127.0.0.1 6480 命令，我們?cè)趤砜纯?6379 的 info replication。

127.0.0.1:6379> info replication # Replication role:slave master_host:127.0.0.1 master_port:6480 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:4367 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:0000000000000000000000000000000000000000 master_repl_offset:4367 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:4368 repl_backlog_histlen:0 127.0.0.1:6379>

6379 節(jié)點(diǎn)的角色已經(jīng)是 slave 了，并且主節(jié)點(diǎn)的是 6480 ，我們可以再看看 6480 節(jié)點(diǎn)的 info replication。

127.0.0.1:6480> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_repl_offset:4479 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4479 127.0.0.1:6480>

在 6480 節(jié)點(diǎn)上有 6379 從節(jié)點(diǎn)的信息，可以看出 slaveof 命令已經(jīng)幫我們完成了主服務(wù)器的切換。

復(fù)制技術(shù)的原理

redis 的主從架構(gòu)好像很簡(jiǎn)單一樣，我們就執(zhí)行了一條命令就成功搭建了主從架構(gòu)，并且數(shù)據(jù)復(fù)制也沒有問題，使用起來確實(shí)簡(jiǎn)單，但是這背后 redis  還是幫我們做了很多的事情，比如主從服務(wù)器之間的數(shù)據(jù)同步、主從服務(wù)器的狀態(tài)檢測(cè)等，這背后 redis 是如何實(shí)現(xiàn)的呢?接下來我們就一起看看。

數(shù)據(jù)復(fù)制原理

我們執(zhí)行完 slaveof 命令之后，我們的主從關(guān)系就建立好了，在這個(gè)過程中， master 服務(wù)器與 slave  服務(wù)器之間需要經(jīng)歷多個(gè)步驟，如下圖所示：

redis 復(fù)制原理

slaveof 命令背后，主從服務(wù)器大致經(jīng)歷了七步，其中權(quán)限驗(yàn)證這一步不是必須的，為了能夠更好的理解這些步驟，就以我們上面搭建的 redis  實(shí)例為例來詳細(xì)聊一聊各步驟。

1、保存主節(jié)點(diǎn)信息

在 6480 的客戶端向 6480 節(jié)點(diǎn)服務(wù)器發(fā)送 slaveof 127.0.0.1 6379 命令時(shí)，我們會(huì)立馬得到一個(gè) OK。

127.0.0.1:6480> slaveof 127.0.0.1 6379 OK 127.0.0.1:6480>

這時(shí)候數(shù)據(jù)復(fù)制工作并沒有開始，數(shù)據(jù)復(fù)制工作是在返回 OK 之后才開始執(zhí)行的，這時(shí)候 6480 從節(jié)點(diǎn)做的事情是將給定的主服務(wù)器 IP 地址  127.0.0.1 以及端口 6379 保存到服務(wù)器狀態(tài)的 masterhost 屬性和 masterport 屬性里面。

2、建立 socket 連接

在 slaveof 命令執(zhí)行完之后，從服務(wù)器會(huì)根據(jù)命令設(shè)置的 IP 地址和端口，跟主服務(wù)器創(chuàng)建套接字連接， 如果從服務(wù)器能夠跟主服務(wù)器成功的建立  socket 連接，那么從服務(wù)器將會(huì)為這個(gè) socket 關(guān)聯(lián)一個(gè)專門用于處理復(fù)制工作的文件事件處理器，這個(gè)處理器將負(fù)責(zé)后續(xù)的復(fù)制工作，比如接受全量復(fù)制的  RDB 文件以及服務(wù)器傳來的寫命令。同樣主服務(wù)器在接受從服務(wù)器的 socket 連接之后，將為該 socket  創(chuàng)建一個(gè)客戶端狀態(tài)，這時(shí)候的從服務(wù)器同時(shí)具有服務(wù)器和客戶端兩個(gè)身份，從服務(wù)器可以向主服務(wù)器發(fā)送命令請(qǐng)求而主服務(wù)器則會(huì)向從服務(wù)器返回命令回復(fù)。

3、發(fā)送 ping 命令

從服務(wù)器與主服務(wù)器連接成功后，做的第一件事情就是向主服務(wù)器發(fā)送一個(gè) ping 命令，發(fā)送 ping 命令主要有以下目的：

• 檢測(cè)主從之間網(wǎng)絡(luò)套接字是否可用

• 檢測(cè)主節(jié)點(diǎn)當(dāng)前是否可接受處理命令

在發(fā)送 ping 命令之后，正常情況下主服務(wù)器會(huì)返回 pong 命令，接受到主服務(wù)器返回的 pong 回復(fù)之后就會(huì)進(jìn)行下一步工作，如果沒有收到主節(jié)點(diǎn)的  pong 回復(fù)或者超時(shí)，比如網(wǎng)絡(luò)超時(shí)或者主節(jié)點(diǎn)正在阻塞無法響應(yīng)命令，從服務(wù)器會(huì)斷開復(fù)制連接，等待下一次定時(shí)任務(wù)的調(diào)度。

4、身份驗(yàn)證

從服務(wù)器在接收到主服務(wù)器返回的 pong 回復(fù)之后，下一步要做的事情就是根據(jù)配置信息決定是否需要身份驗(yàn)證：

• 如果從服務(wù)器設(shè)置了 masterauth 參數(shù)，則進(jìn)行身份驗(yàn)證

• 如果從服務(wù)器沒有設(shè)置 masterauth 參數(shù)，則不進(jìn)行身份驗(yàn)證

在需要身份驗(yàn)證的情況下，從服務(wù)器將就向主服務(wù)器發(fā)送一條 auth 命令，命令參數(shù)為從服務(wù)器 masterauth  選項(xiàng)的值，舉個(gè)例子，如果從服務(wù)器的配置里將 masterauth 參數(shù)設(shè)置為：123456，那么從服務(wù)器將向主服務(wù)器發(fā)送 auth 123456  命令，身份驗(yàn)證的過程也不是一帆風(fēng)順的，可能會(huì)遇到以下幾種情況：

• 從服務(wù)器通過 auth 命令發(fā)送的密碼與主服務(wù)器的 requirepass 參數(shù)值一致，那么將繼續(xù)進(jìn)行后續(xù)操作，如果密碼不一致，主服務(wù)將返回一個(gè)  invalid password 錯(cuò)誤

• 如果主服務(wù)器沒有設(shè)置 requirepass 參數(shù)，那么主服務(wù)器將返回一個(gè) no password is set 錯(cuò)誤

所有的錯(cuò)誤情況都會(huì)令從服務(wù)器中止當(dāng)前的復(fù)制工作，并且要從建立 socket 開始重新發(fā)起復(fù)制流程，直到身份驗(yàn)證通過或者從服務(wù)器放棄執(zhí)行復(fù)制為止。

5、發(fā)送端口信息

在身份驗(yàn)證通過后，從服務(wù)器將執(zhí)行 REPLCONF listening命令，向主服務(wù)器發(fā)送從服務(wù)器的監(jiān)聽端口號(hào)，例如在我們的例子中從服務(wù)器監(jiān)聽的端口為  6480，那么從服務(wù)器將向主服務(wù)器發(fā)送 REPLCONF listening 6480  命令，主服務(wù)器接收到這個(gè)命令之后，會(huì)將端口號(hào)記錄在從服務(wù)器所對(duì)應(yīng)的客戶端狀態(tài)的 slave_listening_port 屬性了，也就是我們?cè)?master  服務(wù)器的 info replication 里面看到的 port 值。

6、數(shù)據(jù)復(fù)制

數(shù)據(jù)復(fù)制是最復(fù)雜的一塊了，由 psync 命令來完成，從服務(wù)器會(huì)向主服務(wù)器發(fā)送一個(gè) psync 命令來進(jìn)行數(shù)據(jù)同步，在 redis 2.8  版本以前使用的是 sync 命令，除了命令不同之外，在復(fù)制的方式上也有很大的不同，在 redis 2.8  版本以前使用的都是全量復(fù)制，這對(duì)主節(jié)點(diǎn)和網(wǎng)絡(luò)會(huì)造成很大的開銷，在 redis 2.8 版本以后，數(shù)據(jù)同步將分為全量同步和部分同步。

• 全量復(fù)制：一般用于初次復(fù)制場(chǎng)景，不管是新舊版本的 redis  在從服務(wù)器第一次與主服務(wù)連接時(shí)都將進(jìn)行一次全量復(fù)制，它會(huì)把主節(jié)點(diǎn)的全部數(shù)據(jù)一次性發(fā)給從節(jié)點(diǎn)，當(dāng)數(shù)據(jù)較大時(shí)，會(huì)對(duì)主節(jié)點(diǎn)和網(wǎng)絡(luò)造成很大的開銷，redis  的早期版本只支持全量復(fù)制，這不是一種高效的數(shù)據(jù)復(fù)制方式

• 部分復(fù)制：用于處理在主從復(fù)制中因網(wǎng)絡(luò)閃斷等原因造成的數(shù)據(jù)丟失 場(chǎng)景，當(dāng)從節(jié)點(diǎn)再次連上主節(jié)點(diǎn)后，如果條件允許，主節(jié)點(diǎn)會(huì)補(bǔ)發(fā)丟失數(shù)據(jù)  給從節(jié)點(diǎn)。因?yàn)檠a(bǔ)發(fā)的數(shù)據(jù)遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù)，可以有效避免全量復(fù)制的過高開銷，部分復(fù)制是對(duì)老版復(fù)制的重大優(yōu)化，有效避免了不必要的全量復(fù)制操作

redis 之所以能夠支持全量復(fù)制和部分復(fù)制，主要是對(duì) sync 命令的優(yōu)化，在 redis 2.8 版本以后使用的是一個(gè)全新的 psync  命令，命令格式為：psync {runId} {offset}，這兩個(gè)參數(shù)的意義：

• runId：主節(jié)點(diǎn)運(yùn)行的id

• offset：當(dāng)前從節(jié)點(diǎn)復(fù)制的數(shù)據(jù)偏移量

也許你對(duì)上面的 runid、offset 比較陌生，沒關(guān)系，我們先來看看下面三個(gè)概念：

1、復(fù)制偏移量

參與復(fù)制的主從節(jié)點(diǎn)都會(huì)分別維護(hù)自身復(fù)制偏移量：主服務(wù)器每次向從服務(wù)器傳播 N 個(gè)字節(jié)的數(shù)據(jù)時(shí)，就將自己的偏移量的值加上  N，從服務(wù)器每次接收到主服務(wù)器傳播的 N個(gè)字節(jié)的數(shù)據(jù)時(shí)，將自己的偏移量值加上  N。通過對(duì)比主從服務(wù)器的復(fù)制偏移量，就可以知道主從服務(wù)器的數(shù)據(jù)是否一致，如果主從服務(wù)器的偏移量總是相同，那么主從數(shù)據(jù)一致，相反，如果主從服務(wù)器兩個(gè)的偏移量并不相同，那么說明主從服務(wù)器并未處于數(shù)據(jù)一致的狀態(tài)，比如在有多個(gè)從服務(wù)器時(shí)，在傳輸?shù)倪^程中某一個(gè)服務(wù)器離線了，如下圖所示：

offset 不一致

由于從服務(wù)器A 在數(shù)據(jù)傳輸時(shí)，由于網(wǎng)絡(luò)原因掉線了，導(dǎo)致偏移量與主服務(wù)器不一致，那么當(dāng)從服務(wù)器A 重啟并且與主服務(wù)器連接成功后，重新向主服務(wù)器發(fā)送  psync 命令，這時(shí)候數(shù)據(jù)復(fù)制應(yīng)該執(zhí)行全量復(fù)制還是部分復(fù)制呢?如果執(zhí)行部分復(fù)制，主服務(wù)器又如何補(bǔ)償從服務(wù)器A  在斷線期間丟失的那部分?jǐn)?shù)據(jù)呢?這些問題的答案都在復(fù)制積壓緩沖區(qū)里面。

2、復(fù)制積壓緩沖區(qū)

復(fù)制積壓緩沖區(qū)是保存在主節(jié)點(diǎn)上的一個(gè)固定長(zhǎng)度的隊(duì)列，默認(rèn)大小為 1MB，當(dāng)主節(jié)點(diǎn)有連接的從節(jié)點(diǎn)(slave)時(shí)被創(chuàng)建，這時(shí)主節(jié)點(diǎn)(master)  響應(yīng)寫命令時(shí)，不但會(huì)把命令發(fā)送給從節(jié)點(diǎn)，還會(huì)寫入復(fù)制積壓緩沖區(qū)，如下圖所示：

復(fù)制積壓緩沖區(qū)

因此，主服務(wù)器的復(fù)制積壓緩沖區(qū)里面會(huì)保存著一部分最近傳播的寫命令，并且復(fù)制積壓緩沖區(qū)會(huì)為隊(duì)列中的每個(gè)字節(jié)記錄相應(yīng)的復(fù)制偏移量。所以當(dāng)從服務(wù)器重新連上主服務(wù)器時(shí)，從服務(wù)器通過  psync 命令將自己的復(fù)制偏移量 offset 發(fā)送給主服務(wù)器，主服務(wù)器會(huì)根據(jù)這個(gè)復(fù)制偏移量來決定對(duì)從服務(wù)器執(zhí)行何種數(shù)據(jù)同步操作：

• 如果從服務(wù)器的復(fù)制偏移量之后的數(shù)據(jù)仍然存在于復(fù)制積壓緩沖區(qū)里面，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行部分復(fù)制操作

• 如果從服務(wù)器的復(fù)制偏移量之后的數(shù)據(jù)不存在于復(fù)制積壓緩沖區(qū)里面，那么主服務(wù)器將對(duì)從服務(wù)器執(zhí)行全量復(fù)制操作

3、服務(wù)器運(yùn)行ID

每個(gè) Redis 節(jié)點(diǎn)啟動(dòng)后都會(huì)動(dòng)態(tài)分配一個(gè) 40 位的十六進(jìn)制字符串作為運(yùn)行 ID，運(yùn)行 ID 的主要作用是用來唯一識(shí)別 Redis 節(jié)點(diǎn)，我們可以使用  info server 命令來查看

127.0.0.1:6379> info server # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:2ef1d58592147923 redis_mode:standalone os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:25214 run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1 tcp_port:6379 uptime_in_seconds:14382 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:14554933 executable:/usr/local/redis-5.0.5/src/./redis-server config_file:/usr/local/redis-5.0.5/redis.conf 127.0.0.1:6379>

這里面有一個(gè)run_id 字段就是服務(wù)器運(yùn)行的ID

了解這幾個(gè)概念之后，我們一起來看看 psync 命令的運(yùn)行流程，psync 命令運(yùn)行流程如下圖所示：

psync 運(yùn)行流程

psync 命令的邏輯比較簡(jiǎn)單，整個(gè)流程分為兩步：

1、從節(jié)點(diǎn)發(fā)送 psync 命令給主節(jié)點(diǎn)，參數(shù) runId  是當(dāng)前從節(jié)點(diǎn)保存的主節(jié)點(diǎn)運(yùn)行ID，參數(shù)offset是當(dāng)前從節(jié)點(diǎn)保存的復(fù)制偏移量，如果是第一次參與復(fù)制則默認(rèn)值為 -1。

2、主節(jié)點(diǎn)接收到 psync 命令之后，會(huì)向從服務(wù)器返回以下三種回復(fù)中的一種：

• 回復(fù) +FULLRESYNC {runId} {offset}：表示主服務(wù)器將與從服務(wù)器執(zhí)行一次全量復(fù)制操作，其中 runid 是這個(gè)主服務(wù)器的運(yùn)行  id，從服務(wù)器會(huì)保存這個(gè)id，在下一次發(fā)送 psync 命令時(shí)使用，而 offset  則是主服務(wù)器當(dāng)前的復(fù)制偏移量，從服務(wù)器會(huì)將這個(gè)值作為自己的初始化偏移量

• 回復(fù) +CONTINUE：那么表示主服務(wù)器與從服務(wù)器將執(zhí)行部分復(fù)制操作，從服務(wù)器只要等著主服務(wù)器將自己缺少的那部分?jǐn)?shù)據(jù)發(fā)送過來就可以了

• 回復(fù) +ERR：那么表示主服務(wù)器的版本低于 redis 2.8，它識(shí)別不了 psync 命令，從服務(wù)器將向主服務(wù)器發(fā)送 sync  命令，并與主服務(wù)器執(zhí)行全量復(fù)制

7、命令持續(xù)復(fù)制

當(dāng)主節(jié)點(diǎn)把當(dāng)前的數(shù)據(jù)同步給從節(jié)點(diǎn)后，便完成了復(fù)制的建立流程。但是主從服務(wù)器并不會(huì)斷開連接，因?yàn)榻酉聛碇鞴?jié)點(diǎn)會(huì)持續(xù)地把寫命令發(fā)送給從節(jié)點(diǎn)，保證主從數(shù)據(jù)一致性。

經(jīng)過上面 7 步就完成了主從服務(wù)器之間的數(shù)據(jù)同步，由于這篇文章的篇幅比較長(zhǎng)，關(guān)于全量復(fù)制和部分復(fù)制的細(xì)節(jié)就不介紹了，全量復(fù)制就是將主節(jié)點(diǎn)的當(dāng)前的數(shù)據(jù)生產(chǎn)  RDB  文件，發(fā)送給從服務(wù)器，從服務(wù)器再從本地磁盤加載，這樣當(dāng)文件過大時(shí)就需要特別大的網(wǎng)絡(luò)開銷，不然由于數(shù)據(jù)傳輸比較慢會(huì)導(dǎo)致主從數(shù)據(jù)延時(shí)較大，部分復(fù)制就是主服務(wù)器將復(fù)制積壓緩沖區(qū)的寫命令直接發(fā)送給從服務(wù)器。

心跳檢測(cè)

心跳檢測(cè)是發(fā)生在主從節(jié)點(diǎn)在建立復(fù)制后，它們之間維護(hù)著長(zhǎng)連接并彼此發(fā)送心跳命令，便以后續(xù)持續(xù)發(fā)送寫命令，主從心跳檢測(cè)如下圖所示：

主從心跳檢測(cè)

主從節(jié)點(diǎn)彼此都有心跳檢測(cè)機(jī)制，各自模擬成對(duì)方的客戶端進(jìn)行通信，主從心跳檢測(cè)的規(guī)則如下：

• 主節(jié)點(diǎn)默認(rèn)每隔 10 秒對(duì)從節(jié)點(diǎn)發(fā)送 ping 命令，判斷從節(jié)點(diǎn)的存活性和連接狀態(tài)?？赏ㄟ^修改 redis.conf 配置文件里面的  repl-ping-replica-period 參數(shù)來控制發(fā)送頻率

• 從節(jié)點(diǎn)在主線程中每隔 1 秒發(fā)送 replconf ack {offset} 命令，給主節(jié)點(diǎn)  上報(bào)自身當(dāng)前的復(fù)制偏移量，這條命令除了檢測(cè)主從節(jié)點(diǎn)網(wǎng)絡(luò)之外，還通過發(fā)送復(fù)制偏移量來保證主從的數(shù)據(jù)一致

主節(jié)點(diǎn)根據(jù) replconf 命令判斷從節(jié)點(diǎn)超時(shí)時(shí)間，體現(xiàn)在 info replication 統(tǒng) 計(jì)中的 lag 信息中，我們?cè)谥鞣?wù)器上執(zhí)行 info  replication 命令：

127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0 master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:25774 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:25774 127.0.0.1:6379>

可以看出 slave0 字段的值最后面有一個(gè) lag，lag 表示與從節(jié)點(diǎn)最后一次通信延遲的秒數(shù)，正常延遲應(yīng)該在 0 和 1 之間。如果超過  repl-timeout 配置的值(默認(rèn)60秒)，則判定從節(jié)點(diǎn)下線并斷開復(fù)制客戶端連接，如果從節(jié)點(diǎn)重新恢復(fù)，心跳檢測(cè)會(huì)繼續(xù)進(jìn)行。

主從拓?fù)浼軜?gòu)

Redis 的主從拓?fù)浣Y(jié)構(gòu)可以支持單層或多層復(fù)制關(guān)系，根據(jù)拓?fù)鋸?fù)雜性可以分為以下三種：一主一從、一主多從、樹狀主從架構(gòu)。

一主一從結(jié)構(gòu)

一主一從結(jié)構(gòu)是最簡(jiǎn)單的復(fù)制拓?fù)浣Y(jié)構(gòu)，我們前面搭建的就是一主一從的架構(gòu)，架構(gòu)如圖所示：

一主一從架構(gòu)

一主一從架構(gòu)

用于主節(jié)點(diǎn)出現(xiàn)宕機(jī)時(shí)從節(jié)點(diǎn) 提供故障轉(zhuǎn)移支持，當(dāng)應(yīng)用寫命令并發(fā)量較高且需要持久化時(shí)，可以只在從節(jié)點(diǎn)上開啟  AOF，這樣既保證數(shù)據(jù)安全性同時(shí)也避免了持久化對(duì)主節(jié)點(diǎn)的性能干擾。但是這里有一個(gè)坑，需要你注意，就是當(dāng)主節(jié)點(diǎn)關(guān)閉持久化功能時(shí)，  如果主節(jié)點(diǎn)脫機(jī)要避免自動(dòng)重啟操作。因?yàn)橹鞴?jié)點(diǎn)之前沒有開啟持久化功能自動(dòng)重啟后數(shù)據(jù)集為空，這時(shí)從節(jié)點(diǎn)如果繼續(xù)復(fù)制主節(jié)點(diǎn)會(huì)導(dǎo)致從節(jié)點(diǎn)數(shù)據(jù)也被清空的情況，喪失了持久化的意義。安全的做法是在從節(jié)點(diǎn)上執(zhí)行  slaveof no one 斷開與主節(jié)點(diǎn)的復(fù)制關(guān)系，再重啟主節(jié)點(diǎn)從而避免這一問題。

一主多從架構(gòu)一主多從架構(gòu)又稱為星形拓?fù)浣Y(jié)構(gòu)，一主多從架構(gòu)如下圖所示：

一主多從架構(gòu)

一主多從架構(gòu)可以實(shí)現(xiàn)讀寫分離來減輕主服務(wù)器的壓力，對(duì)于讀占比較大的場(chǎng)景，可以把讀命令發(fā)送到  從節(jié)點(diǎn)來分擔(dān)主節(jié)點(diǎn)壓力。同時(shí)在日常開發(fā)中如果需要執(zhí)行一些比較耗時(shí)的讀命令，如：keys、sort等，可以在其中一臺(tái)從節(jié)點(diǎn)上執(zhí)行，防止慢查詢對(duì)主節(jié)點(diǎn)造成阻塞從而影響線上服務(wù)的穩(wěn)定性。對(duì)于寫并發(fā)量較高的場(chǎng)景，多個(gè)從節(jié)點(diǎn)會(huì)導(dǎo)致主節(jié)點(diǎn)寫命令的多次發(fā)送從而過度消耗網(wǎng)絡(luò)帶寬，同時(shí)也加重了主節(jié)點(diǎn)的負(fù)載影響服務(wù)穩(wěn)定性。

樹狀主從架構(gòu)

樹狀主從架構(gòu)又稱為樹狀拓?fù)浼軜?gòu)，樹狀主從架構(gòu)如下圖所示：

樹狀主從架構(gòu)

樹狀主從架構(gòu)使得從節(jié)點(diǎn)不但可以復(fù)制主節(jié) 數(shù)據(jù)，同時(shí)可以作為其他從節(jié)點(diǎn)的主節(jié)點(diǎn)繼續(xù)向下層復(fù)制。解決了一主多從架構(gòu)中的不足，通過引入復(fù)制中  間層，可以有效降低主節(jié)點(diǎn)負(fù)載和需要傳送給從節(jié)點(diǎn)的數(shù)據(jù)量。如架構(gòu)圖中，數(shù)據(jù)寫入節(jié)點(diǎn)A 后會(huì)同步到 B 和 C節(jié)點(diǎn)，B節(jié)點(diǎn)再把數(shù)據(jù)同步到 D 和  E節(jié)點(diǎn)，數(shù)據(jù)實(shí)現(xiàn)了一層一層的向下復(fù)制。當(dāng)主節(jié)點(diǎn)需要掛載多個(gè)從節(jié)點(diǎn)時(shí)為了避免對(duì)主節(jié)點(diǎn)的性能干擾，可以采用樹狀主從結(jié)構(gòu)降低主節(jié)點(diǎn)壓力。

關(guān)于“Redis主從架構(gòu)的建立方式有哪些”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“Redis主從架構(gòu)的建立方式有哪些”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。