前言

只有光頭才能變強

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了未央免費建站歡迎大家使用！

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

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

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

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

這篇文章主要講的是Redis主從復(fù)制。因為Redis集群的知識點有點多，所以鉑金上分得要好幾篇~

文本力求簡單講清每個知識點，希望大家看完能有所收獲

一、主從架構(gòu)

1.1為什么要主從架構(gòu)

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

因為Redis如果只有一臺服務(wù)器的話，那隨著請求越來越多：

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

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

• 萬一這臺Redis掛了，所有的請求全走關(guān)系數(shù)據(jù)庫了，那就更炸了。

顯然，出現(xiàn)的上述問題是因為一臺Redis服務(wù)器不夠，所以多搞幾臺Redis服務(wù)器就可以了

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

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

1.2主從架構(gòu)的特點

下面我們來看看Redis的主從架構(gòu)特點：

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

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

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

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

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

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

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

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

二、復(fù)制功能

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

因為主服務(wù)器是能接收寫請求的，主服務(wù)器處理完寫請求，會做什么來保證主從數(shù)據(jù)的一致性呢？如果主從服務(wù)器斷開了，過一陣子才重連，又會怎么處理呢？下面將會了解到這些細節(jié)~

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

2.1復(fù)制功能的具體實現(xiàn)

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

• 同步(sync)

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

• 命令傳播(command propagate)

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

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

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

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

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

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

2.1.1復(fù)制的前置工作

首先我們來看一下前置的工作：

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

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

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

• 身份驗證(看有沒有設(shè)置對應(yīng)的驗證配置)

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

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

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

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

2.1.2完整重同步

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

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

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

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

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

2.1.2部分重同步

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

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

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

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

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

首先我們來解釋一下上面的名詞：

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

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

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

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

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

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

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

所以流程大概如此：

2.1.3命令傳播

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

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

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

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

• 輔助實現(xiàn)min-slaves選項

• 檢測命令丟失

五、最后

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

拋個問題：如果從服務(wù)器掛了，沒關(guān)系，我們一般會有多個從服務(wù)器，其他的請求可以交由沒有掛的從服務(wù)器繼續(xù)處理。如果主服務(wù)器掛了，怎么辦？因為我們的寫請求由主服務(wù)器處理，只有一臺主服務(wù)器，那就無法處理寫請求了？

問題留到下篇解決~