讀者訴苦：Redis 宕機，數(shù)據(jù)丟了，老板要辭退我

大家好，我是Tom哥~

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

我也很好奇，問小哥Redis主節(jié)點掛了，還有備機啊。怎么會影響到業(yè)務呢？

小哥說，他們的系統(tǒng)架構只部署一個Redis單實例。節(jié)點掛了，數(shù)據(jù)也丟了。

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

首先，什么是主從？

主從也稱主從集群，部署了多個Redis實例，如下圖所示：

其中，每個實例又有自己的專屬職責

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

好奇的寶寶可能要問了，為什么從庫不能寫？

考慮到數(shù)據(jù)合并的復雜性，假如一個key，多次更新，每次操作在不同的實例上執(zhí)行，為了保證數(shù)據(jù)的全局一致性，勢必要加全局鎖，保證在集群范圍上串行化操作且在最新的數(shù)據(jù)基礎上更新，這個成本還是很大的。

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

可能有同學會提到 Redis Cluster 模式，這個是另一種設計方案。采用水平分割方式，通過CRC16（key）算法，將數(shù)據(jù)拆分到若干個實例中，每個實例只對自己負責的槽位的數(shù)據(jù)讀、寫，從而分攤集群壓力。這個屬于另一種玩法，本期就不深入展開了。

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

1、RDB，全量數(shù)據(jù)同步

2、AOF，增量數(shù)據(jù)同步，回放日志

這兩者有什么區(qū)別？

什么時候采用 RDB ? 什么時候采用 AOF ?

接下來，我們逐步分析展開

建立主從關系

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

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

replicaof?192.168.0.1?6379

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

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

主從同步

1、第一步

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

• 第一次建立連接時，從庫并不知道主庫的runID，所以會設置為 ？。offset = -1，表示第一次復制。

主庫接收到psync請求后，會響應 FULLRESYNC ，帶有兩個參數(shù)（主庫的runID和同步進度offset）

2、第二步

• 主庫fork子進程，執(zhí)行?bgsave?命令，生成 RDB 文件
• 主庫將 RDB 文件發(fā)給從庫
• 從庫接到響應后，會先清空當前數(shù)據(jù)庫，然后加載 RDB 文件

3、第三步

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

到這里，主從的核心邏輯基本講完了。

但生產環(huán)境，通常是一主多從，每個從庫初始同步時，都要主庫生成RDB文件，顯然開銷很大。有什么解決方案？

一主多從，主庫減壓

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

1、當從庫同步主庫時，要fork子進程，有多少個從節(jié)點，就要fork多少個子進程，每個子進程都要生成RDB。導致主庫系統(tǒng)壓力過大

2、生成的RDB要同步給從庫，占用網絡帶寬

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

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

任何事情都不是一成不變的，網絡傳輸就存在很大的風險，網絡閃斷了怎么辦？對主從同步有什么影響？

網絡閃斷對主從同步的影響

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

這里要引入一個緩沖區(qū)，repl_backlog_buffer，它是一個環(huán)形設計，增量命令都是先存入這個緩沖區(qū)的。主庫有生產位移，稱之為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)形結構，如果主庫的生產速度比從庫的拉取速度快很多時，就會出現(xiàn)套圈現(xiàn)象。

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

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

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

有兩個解決方案：

1、調大?repl_backlog_buffer?緩沖區(qū)大小，該值是由?repl_backlog_size參數(shù)控制

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

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

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

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

如果只是傳統(tǒng)意義上的主從模式，主節(jié)點掛了，通常要手工完成切換。

效率不言而喻了，尤其是線上生產系統(tǒng)，根本沒法接受這種方案。

這時候，要引入哨兵機制了，哨兵機制可以實現(xiàn)主從庫的自動切換，有效解決了故障轉移。整個過程分為三個階段：監(jiān)控、選主、通知。

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

當然，網絡抖動，也會存在誤判可能，如何避免？

引入哨兵集群，多個哨兵實例一起判斷，降低誤判率。判斷標準就是，假如 n 個哨兵實例，至少有 n/2+1 個判定一致，才可以定論。

2、選主。主要是看各個節(jié)點的打分情況，打分規(guī)則分為?從庫優(yōu)先級、從庫復制進度、從庫ID號。只要有一輪，某個從庫得分最高，則選舉它為主庫。

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

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