摘要：前言只有光頭才能變強(qiáng)好的，今天我們要上鉑金段位了，如果還沒(méi)經(jīng)歷過(guò)青銅和白銀和黃金階段的，可以先去蹭蹭經(jīng)驗(yàn)再回來(lái)從零單排學(xué)青銅從零單排學(xué)白銀從零單排學(xué)黃金這篇文章主要講的是主從復(fù)制。

只有光頭才能變強(qiáng)

好的，今天我們要上鉑金段位了，如果還沒(méi)經(jīng)歷過(guò)青銅和白銀和黃金階段的，可以先去蹭蹭經(jīng)驗(yàn)再回來(lái)：

從零單排學(xué)Redis【青銅】

從零單排學(xué)Redis【白銀】

從零單排學(xué)Redis【黃金】

這篇文章主要講的是Redis主從復(fù)制。因?yàn)镽edis集群的知識(shí)點(diǎn)有點(diǎn)多，所以鉑金上分得要好幾篇~

文本力求簡(jiǎn)單講清每個(gè)知識(shí)點(diǎn)，希望大家看完能有所收獲

Redis也跟關(guān)系型數(shù)據(jù)(MySQL)一樣，如果有過(guò)多請(qǐng)求還是撐不住的。

因?yàn)镽edis如果只有一臺(tái)服務(wù)器的話，那隨著請(qǐng)求越來(lái)越多：

Redis的內(nèi)存是有限的，可能放不下那么多的數(shù)據(jù)

單臺(tái)Redis支持的并發(fā)量也是有限的。

萬(wàn)一這臺(tái)Redis掛了，所有的請(qǐng)求全走關(guān)系數(shù)據(jù)庫(kù)了，那就更炸了。

顯然，出現(xiàn)的上述問(wèn)題是因?yàn)橐慌_(tái)Redis服務(wù)器不夠，所以多搞幾臺(tái)Redis服務(wù)器就可以了

為了實(shí)現(xiàn)我們服務(wù)的高可用性，可以將這幾臺(tái)Redis服務(wù)器做成是主從來(lái)進(jìn)行管理

tip:Redis作者已將Master/Slave架構(gòu)改名為Master/Replica

下面我們來(lái)看看Redis的主從架構(gòu)特點(diǎn)：

主服務(wù)器負(fù)責(zé)接收寫請(qǐng)求

從服務(wù)器負(fù)責(zé)接收讀請(qǐng)求

從服務(wù)器的數(shù)據(jù)由主服務(wù)器復(fù)制過(guò)去。主從服務(wù)器的數(shù)據(jù)是一致的

主從架構(gòu)的好處：

讀寫分離(主服務(wù)器負(fù)責(zé)寫，從服務(wù)器負(fù)責(zé)讀)

高可用(某一臺(tái)從服務(wù)器掛了，其他從服務(wù)器還能繼續(xù)接收請(qǐng)求，不影響服務(wù))

處理更多的并發(fā)量(每臺(tái)從服務(wù)器都可以接收讀請(qǐng)求，讀QPS就上去了)

主從架構(gòu)除了上面的形式，也有下面這種的(只不過(guò)用得比較少)：

主從架構(gòu)的特點(diǎn)之一：主服務(wù)器和從服務(wù)器的數(shù)據(jù)是一致的。

因?yàn)橹鞣?wù)器是能接收寫請(qǐng)求的，主服務(wù)器處理完寫請(qǐng)求，會(huì)做什么來(lái)保證主從數(shù)據(jù)的一致性呢？如果主從服務(wù)器斷開了，過(guò)一陣子才重連，又會(huì)怎么處理呢？下面將會(huì)了解到這些細(xì)節(jié)~

在Redis中，用戶可以通過(guò)執(zhí)行SALVEOF命令或者設(shè)置salveof選項(xiàng)，讓一個(gè)服務(wù)器去復(fù)制(replicate)另一個(gè)服務(wù)器，我們稱呼被復(fù)制的服務(wù)器為主服務(wù)器(master)，而對(duì)主服務(wù)器進(jìn)行復(fù)制的服務(wù)器則被稱為從服務(wù)器(salve)

復(fù)制功能分為兩個(gè)操作：

同步(sync)

將從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)更新至主服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)

命令傳播(command propagate)

主服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)被修改，導(dǎo)致主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)不一致，讓主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)重新回到一致狀態(tài)。

從服務(wù)器對(duì)主服務(wù)器的同步又可以分為兩種情況：

初次同步：從服務(wù)器沒(méi)有復(fù)制過(guò)任何的主服務(wù)器，或者從服務(wù)器要復(fù)制的主服務(wù)器跟上次復(fù)制的主服務(wù)器不一樣。

斷線后同步：處于命令傳播階段的主從服務(wù)器因?yàn)?strong>網(wǎng)絡(luò)原因中斷了復(fù)制，從服務(wù)器通過(guò)自動(dòng)重連重新連接主服務(wù)器，并繼續(xù)復(fù)制主服務(wù)器

在Redis2.8以前，斷線后復(fù)制這部分其實(shí)缺少的只是部分的數(shù)據(jù)，但是要讓主從服務(wù)器重新執(zhí)行SYNC命令，這樣的做法是非常低效的。(因?yàn)閳?zhí)行SYNC命令是把所有的數(shù)據(jù)再次同步，而不是只同步丟失的數(shù)據(jù))

接下來(lái)我們來(lái)詳細(xì)看看Redis2.8以后復(fù)制功能是怎么實(shí)現(xiàn)的：

首先我們來(lái)看一下前置的工作：

從服務(wù)器設(shè)置主服務(wù)器的IP和端口

建立與主服務(wù)器的Socket連接

發(fā)送PING命令(檢測(cè)Socket讀寫是否正常與主服務(wù)器的通信狀況)

身份驗(yàn)證(看有沒(méi)有設(shè)置對(duì)應(yīng)的驗(yàn)證配置)

從服務(wù)器給主服務(wù)器發(fā)送端口的信息，主服務(wù)器記錄監(jiān)聽的端口

前面也提到了，Redis2.8之前，斷線后同步會(huì)重新執(zhí)行SYNC命令，這是非常低效的。下面我們來(lái)看一下Redis2.8之后是怎么進(jìn)行同步的。

Redis從2.8版本開始，使用PSYNC命令來(lái)替代SYNC命令執(zhí)行復(fù)制時(shí)同步的操作。

PSYNC命令具有完整重同步和部分重同步兩種模式(其實(shí)就跟上面所說(shuō)的初次復(fù)制和斷線后復(fù)制差不多個(gè)意思)。

下面先來(lái)看看完整重同步是怎么實(shí)現(xiàn)的：

從服務(wù)器向主服務(wù)器發(fā)送PSYNC命令

收到PSYNC命令的主服務(wù)器執(zhí)行BGSAVE命令，在后臺(tái)生成一個(gè)RDB文件。并用一個(gè)緩沖區(qū)來(lái)記錄從現(xiàn)在開始執(zhí)行的所有寫命令。

當(dāng)主服務(wù)器的BGSAVE命令執(zhí)行完后，將生成的RDB文件發(fā)送給從服務(wù)器，從服務(wù)器接收和載入RBD文件。將自己的數(shù)據(jù)庫(kù)狀態(tài)更新至與主服務(wù)器執(zhí)行BGSAVE命令時(shí)的狀態(tài)。

主服務(wù)器將所有緩沖區(qū)的寫命令發(fā)送給從服務(wù)器，從服務(wù)器執(zhí)行這些寫命令，達(dá)到數(shù)據(jù)最終一致性。

接下來(lái)我們來(lái)看看部分重同步，部分重同步可以讓我們斷線后重連只需要同步缺失的數(shù)據(jù)(而不是Redis2.8之前的同步全部數(shù)據(jù))，這是符合邏輯的！

部分重同步功能由以下部分組成：

主從服務(wù)器的復(fù)制偏移量

主服務(wù)器的復(fù)制積壓緩沖區(qū)

服務(wù)器運(yùn)行的ID(run ID)

首先我們來(lái)解釋一下上面的名詞：

復(fù)制偏移量：執(zhí)行復(fù)制的雙方都會(huì)分別維護(hù)一個(gè)復(fù)制偏移量

主服務(wù)器每次傳播N個(gè)字節(jié)，就將自己的復(fù)制偏移量加上N

從服務(wù)器每次收到主服務(wù)器的N個(gè)字節(jié)，就將自己的復(fù)制偏移量加上N

通過(guò)對(duì)比主從復(fù)制的偏移量，就很容易知道主從服務(wù)器的數(shù)據(jù)是否處于一致性的狀態(tài)！

那斷線重連以后，從服務(wù)器向主服務(wù)器發(fā)送PSYNC命令，報(bào)告現(xiàn)在的偏移量是36，那么主服務(wù)器該對(duì)從服務(wù)器執(zhí)行完整重同步還是部分重同步呢？？這就交由復(fù)制積壓緩沖區(qū)來(lái)決定。

當(dāng)主服務(wù)器進(jìn)行命令傳播時(shí)，不僅僅會(huì)將寫命令發(fā)送給所有的從服務(wù)器，還會(huì)將寫命令入隊(duì)到復(fù)制積壓緩沖區(qū)里面(這個(gè)大小可以調(diào)的)。如果復(fù)制積壓緩沖區(qū)存在丟失的偏移量的數(shù)據(jù)，那就執(zhí)行部分重同步，否則執(zhí)行完整重同步。

服務(wù)器運(yùn)行的ID(run ID)實(shí)際上就是用來(lái)比對(duì)ID是否相同。如果不相同，則說(shuō)明從服務(wù)器斷線之前復(fù)制的主服務(wù)器和當(dāng)前連接的主服務(wù)器是兩臺(tái)服務(wù)器，這就會(huì)進(jìn)行完整重同步。

所以流程大概如此：

當(dāng)完成了同步之后，主從服務(wù)器就會(huì)進(jìn)入命令傳播階段。這時(shí)主服務(wù)器只要將自己的寫命令發(fā)送給從服務(wù)器，而從服務(wù)器接收并執(zhí)行主服務(wù)器發(fā)送過(guò)來(lái)的寫命令，就可以保證主從服務(wù)器一直保持?jǐn)?shù)據(jù)一致了！

在命令傳播階段，從服務(wù)器默認(rèn)會(huì)以每秒一次的頻率，向服務(wù)器發(fā)送命令REPLCONF ACK 其中replication_offset是從服務(wù)器當(dāng)前的復(fù)制偏移量

發(fā)送這個(gè)命令主要有三個(gè)作用：

檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)狀態(tài)

輔助實(shí)現(xiàn)min-slaves選項(xiàng)

檢測(cè)命令丟失

畫了好久好久的圖，終于寫完啦。

拋個(gè)問(wèn)題：如果從服務(wù)器掛了，沒(méi)關(guān)系，我們一般會(huì)有多個(gè)從服務(wù)器，其他的請(qǐng)求可以交由沒(méi)有掛的從服務(wù)器繼續(xù)處理。如果主服務(wù)器掛了，怎么辦？因?yàn)槲覀兊膶懻?qǐng)求由主服務(wù)器處理，只有一臺(tái)主服務(wù)器，那就無(wú)法處理寫請(qǐng)求了？

問(wèn)題留到下篇解決~~

參考資料：

《Redis設(shè)計(jì)與實(shí)現(xiàn)》

《Redis實(shí)戰(zhàn)》

如果你覺(jué)得我寫得還不錯(cuò)，了解一下：

堅(jiān)持原創(chuàng)的技術(shù)公眾號(hào)：Java3y?；貜?fù) 1 加入Java交流群

文章的目錄導(dǎo)航(精美腦圖+海量視頻資源)：https://github.com/ZhongFuCheng3y/3y