最近跟一位讀者聊天，小哥非常郁悶，公司的 Redis 宕機了，線上業(yè)務(wù)受到了影響，老板非常憤怒，小哥擔(dān)心會不會被辭退!

[[437482]]

圖片來自 包圖網(wǎng)

我也很好奇，問小哥 Redis 主節(jié)點掛了，還有備機啊。怎么會影響到業(yè)務(wù)呢?小哥說，他們的系統(tǒng)架構(gòu)只部署一個 Redis 單實例。節(jié)點掛了，數(shù)據(jù)也丟了。

[[437483]]

好吧，既然提到了備份，那今天，我們就來聊下 Redis 的主從同步。

首先，什么是主從?主從也稱主從集群，部署了多個 Redis 實例，如下圖所示：

其中，每個實例又有自己的專屬職責(zé)：

• 主庫：負(fù)責(zé)接收讀操作、寫操作
• 從庫：定期同步主庫的數(shù)據(jù)，對外提供讀操作

好奇的寶寶可能要問了，為什么從庫不能寫?考慮到數(shù)據(jù)合并的復(fù)雜性，假如一個 key，多次更新，每次操作在不同的實例上執(zhí)行，為了保證數(shù)據(jù)的全局一致性，勢必要加全局鎖。

保證在集群范圍上串行化操作且在最新的數(shù)據(jù)基礎(chǔ)上更新，這個成本還是很大的。

為了降低系統(tǒng)復(fù)雜度，節(jié)約成本。主從同步架構(gòu)方案一般都是在主庫上寫，在從庫上讀。分工明確，職責(zé)單一。

可能有同學(xué)會提到 Redis Cluster 模式，這個是另一種設(shè)計方案。采用水平分割方式，通過 CRC16(key)算法，將數(shù)據(jù)拆分到若干個實例中。

每個實例只對自己負(fù)責(zé)的槽位的數(shù)據(jù)讀、寫，從而分?jǐn)偧簤毫?。這個屬于另一種玩法，本期就不深入展開了。

為了保證數(shù)據(jù)不丟失，Redis 提供兩種數(shù)據(jù)同步方式：

• RDB，全量數(shù)據(jù)同步
• AOF，增量數(shù)據(jù)同步，回放日志

這兩者有什么區(qū)別?什么時候采用 RDB ? 什么時候采用 AOF ?接下來，我們逐步分析展開。

建立主從關(guān)系

首先，啟動兩個 redis 實例，IP 地址分別是 192.168.0.1 和 192.168.0.2 ，開始時，他們之間沒有任何關(guān)聯(lián)。

我們通過終端命令，登錄 192.168.0.2 機器，執(zhí)行命令：

replicaof 192.168.0.1 6379 

此時 192.168.0.2 實例就成了 192.168.0.1 的從庫。

當(dāng)主從實例建立好關(guān)聯(lián)后，接下來，就開始進入數(shù)據(jù)同步環(huán)節(jié)。

主從同步

主從庫數(shù)據(jù)同步分為三步：

第一步：從庫(192.1768.0.2)向主庫(192.168.0.1)發(fā)送 psync 命令，帶了兩個參數(shù)(主庫的 runID 和同步進度 offset)。

第一次建立連接時，從庫并不知道主庫的 runID，所以會設(shè)置為?。offset = -1，表示第一次復(fù)制。

說明：每個 Redis 實例初始啟動時，會自動生成一個隨機 ID，用來標(biāo)識當(dāng)前實例。

主庫接收到 psync 請求后，會響應(yīng) FULLRESYNC ，帶有兩個參數(shù)(主庫的 runID 和同步進度 offset)。說明：FULLRESYNC 表示采用全量復(fù)制。

第二步：主庫 fork 子進程，執(zhí)行 bgsave 命令，生成 RDB 文件;主庫將 RDB 文件發(fā)給從庫;從庫接到響應(yīng)后，會先清空當(dāng)前數(shù)據(jù)庫，然后加載 RDB 文件。

說明：主庫在生成 RDB 文件時，主線程是阻塞的，對外不提供服務(wù)。一旦 RDB 文件生成，在數(shù)據(jù)同步過程中，不受影響，主庫可以對外服務(wù)。后續(xù)的寫命令數(shù)據(jù)會存到 replication buffer。

第三步：主庫將增量寫命令發(fā)送給從庫，從庫放映式執(zhí)行這些命令，從而實現(xiàn)了主從同步。

到這里，主從的核心邏輯基本講完了。但生產(chǎn)環(huán)境，通常是一主多從，每個從庫初始同步時，都要主庫生成 RDB 文件，顯然開銷很大。有什么解決方案?

一主多從，主庫減壓

當(dāng)從節(jié)點存在多個時，主庫的壓力顯著增加，具體體現(xiàn)在兩個方面：

• 當(dāng)從庫同步主庫時，要 fork 子進程，有多少個從節(jié)點，就要 fork 多少個子進程，每個子進程都要生成 RDB。導(dǎo)致主庫系統(tǒng)壓力過大。
• 生成的 RDB 要同步給從庫，占用網(wǎng)絡(luò)帶寬。

基于上面的困境，演化出新的模式，“主--從--從”模式，具體玩法如下圖：

現(xiàn)有雖然有四個從庫，但直接跟主庫關(guān)聯(lián)同步數(shù)據(jù)的只有 192.168.0.2 和 192.168.0.3 兩個實例，大大減輕了主庫的壓力。

任何事情都不是一成不變的，網(wǎng)絡(luò)傳輸就存在很大的風(fēng)險，網(wǎng)絡(luò)閃斷了怎么辦?對主從同步有什么影響?

網(wǎng)絡(luò)閃斷對主從同步的影響

我們知道主從實例間同步數(shù)據(jù)主要有兩種方式：全量同步和增量同步。全量同步就是同步 RDB 文件，那增量同步是如何實現(xiàn)的呢?

這里要引入一個緩沖區(qū)，repl_backlog_buffer，它是一個環(huán)形設(shè)計，增量命令都是先存入這個緩沖區(qū)的。

主庫有生產(chǎn)位移，稱之為master_repl_offset 。從庫有拉取位移，稱之為slave_repl_offset。

正常情況下，master_repl_offset 和 slave_repl_offset 大小是接近的，也就是說主從庫兩者間的數(shù)據(jù)近乎同步。

每次同步數(shù)據(jù)時，從庫向主庫發(fā)送 psync 命令，把自己的 slave_repl_offset 發(fā)給主庫，主庫基于此偏移位置，向從庫發(fā)送增量數(shù)據(jù)。這個很容易理解。

是不是就萬無一失了呢?由于采用了環(huán)形結(jié)構(gòu)，如果主庫的生產(chǎn)速度比從庫的拉取速度快很多時，就會出現(xiàn)套圈現(xiàn)象。

為什么采用環(huán)形?主要為了讓空間循環(huán)使用，像市場的行車記錄儀、監(jiān)控設(shè)備等，大多都是采用循環(huán)覆蓋式存儲。

如果空間滿了，將之前最老的數(shù)據(jù)覆蓋掉。雖然可能丟失了部分?jǐn)?shù)據(jù)，但是性價比高。

回到上面的問題，如果被套圈了怎么辦?

如上圖所示，從庫 psync 命令，請求的 offset 是 4，但是主節(jié)點已經(jīng)生產(chǎn)到了 15 ，將之前的 1、2、3、4、5 全部覆蓋掉了。

這下傻眼了，需要同步的數(shù)據(jù)被覆蓋了，惹大麻煩了....

[[437488]]

有兩個解決方案：

①調(diào)大 repl_backlog_buffer 緩沖區(qū)大小，該值是由 repl_backlog_size 參數(shù)控制

緩沖空間大小 = 主庫寫入速度 * 操作大小 - 從庫拉取速度 * 操作大小。

這是我們能主觀控制的。比如擔(dān)心大促帶來的流量高峰，可以將這個值調(diào)大 2 倍、3 倍、4 倍，大家可以根據(jù)自己的業(yè)務(wù)情況自由設(shè)置。

②還有一種方式是 Redis 自身提供的解決方案

此時會觸發(fā)全量復(fù)制，跟第一次建立主從關(guān)系同步數(shù)據(jù)一樣。通過全量方式，一次性彌補主從間的數(shù)據(jù)大缺口。

主節(jié)點掛了怎么辦

如果只是傳統(tǒng)意義上的主從模式，主節(jié)點掛了，通常要手工完成切換。效率不言而喻了，尤其是線上生產(chǎn)系統(tǒng)，根本沒法接受這種方案。

這時候，要引入哨兵機制了，哨兵機制可以實現(xiàn)主從庫的自動切換，有效解決了故障轉(zhuǎn)移。

整個過程分為三個階段：

• 監(jiān)控
• 選主
• 通知

監(jiān)控：哨兵進程會周期給所有的主庫、從庫發(fā)送 PING 命令，檢測機器是否處于服務(wù)狀態(tài)。如果沒有在設(shè)置時間內(nèi)收到回復(fù)，則判定為下線。

當(dāng)然，網(wǎng)絡(luò)抖動，也會存在誤判可能，如何避免?引入哨兵集群，多個哨兵實例一起判斷，降低誤判率。判斷標(biāo)準(zhǔn)就是，假如 n 個哨兵實例，至少有 n/2+1 個判定一致，才可以定論。

選主：主要是看各個節(jié)點的打分情況，打分規(guī)則分為從庫優(yōu)先級、從庫復(fù)制進度、從庫 ID 號。

只要有一輪，某個從庫得分最高，則選舉它為主庫：

• 從庫優(yōu)先級，主要是考慮到不同的機器可能配置不一樣，配置高的機器，優(yōu)先級高一些，通過 slave-priority 來配置。
• 從庫復(fù)制進度，主要是看 slave_repl_offset 的值大小，值越大表示已經(jīng)同步的數(shù)據(jù)越多，得分越高。
• 從庫 ID 號，每個 Redis 實例啟動時，都會生成一個 ID，在優(yōu)先級和復(fù)制進度相同的條件下，ID 號最小的從庫分?jǐn)?shù)最高，會被選為新主庫。

通知：把選舉后的新主庫發(fā)送給所有節(jié)點，讓所有的從庫執(zhí)行 replicaof 命令，和 master 建立主從關(guān)系、數(shù)據(jù)同步復(fù)制。另外，也會把最新的主庫信息同步給客戶端。

作者：Tom 哥，前阿里 P7 技術(shù)專家

編輯：陶家龍

來源：轉(zhuǎn)載自公眾號微觀技術(shù)(ID：weiguanjishu)