1. 引言

之前我們聊過 Redis 的數(shù)據(jù)結(jié)構(gòu)底層原理和持久化機(jī)制，這期我們來聊 Redis 的高可用主題。

時光穿梭機(jī)：

• Redis持久化都說不明白？那今天先到這吧~
• Redis數(shù)據(jù)結(jié)構(gòu)的底層原理

眾所周知，一個數(shù)據(jù)庫系統(tǒng)想要實(shí)現(xiàn)高可用，主要從以下兩個方面來考慮：

1. 保證數(shù)據(jù)安全不丟失
2. 系統(tǒng)可以正常提供服務(wù)

而 Redis 作為一個提供高效緩存服務(wù)的數(shù)據(jù)庫，也不例外。

上期我們提到的 Redis 持久化策略，其實(shí)就是為了減少服務(wù)宕機(jī)后數(shù)據(jù)丟失，以及快速恢復(fù)數(shù)據(jù)，也算是支持高可用的一種實(shí)現(xiàn)。

除此之外，Redis 還提供了其它幾種方式來保證系統(tǒng)高可用，業(yè)務(wù)中最常用的莫過于主從同步（也稱作主從復(fù)制）、Sentinel 哨兵機(jī)制以及 Cluster 集群。

同時，這也是面試中出現(xiàn)頻率最高的幾個主題，這期我們先來講講 Redis 的主從復(fù)制。

2. 主從復(fù)制簡介

Redis 同時支持主從復(fù)制和讀寫分離：一個 Redis 實(shí)例作為主節(jié)點(diǎn) Master，負(fù)責(zé)寫操作。其它實(shí)例（可能有 1 或多個）作為從節(jié)點(diǎn) Slave，負(fù)責(zé)復(fù)制主節(jié)點(diǎn)的數(shù)據(jù)。

2.1 架構(gòu)組件

主節(jié)點(diǎn)Master

數(shù)據(jù)更新：Master 負(fù)責(zé)處理所有的寫操作，包括寫入、更新和刪除等。

數(shù)據(jù)同步：寫操作在 Master 上執(zhí)行，然后 Master 將寫操作的結(jié)果同步到所有從節(jié)點(diǎn) Slave 上。

從節(jié)點(diǎn)Slave

數(shù)據(jù)讀取：Slave 負(fù)責(zé)處理讀操作，例如獲取數(shù)據(jù)、查詢等。

數(shù)據(jù)同步：Slave 從 Master 復(fù)制數(shù)據(jù)，并在本地保存一份與主節(jié)點(diǎn)相同的數(shù)據(jù)副本。

2.2 為什么要讀寫分離

1）防止并發(fā)

從上圖我們可以看出，數(shù)據(jù)是由主節(jié)點(diǎn)向從節(jié)點(diǎn)單向復(fù)制的，如果主、從節(jié)點(diǎn)都可以寫入數(shù)據(jù)的話，那么數(shù)據(jù)的一致性如何保證呢？

有聰明的小伙伴可能已經(jīng)想到了，那就是加鎖！

但是主、從節(jié)點(diǎn)分布在不同的服務(wù)器上，數(shù)據(jù)跨節(jié)點(diǎn)同步時又會出現(xiàn)分布式一致性的問題。而在高頻并發(fā)的場景下，解決加鎖后往往又會帶來其它的分布式問題，例如寫入效率低、吞吐量大幅下降等。

而對于 Redis 這樣一個高效緩存數(shù)據(jù)庫來說，性能降低是難以忍受的，所以加鎖不是一個優(yōu)秀的方案。

那如果不加鎖，使用最終一致性方式呢？

這樣 Redis 在主、從庫讀到的數(shù)據(jù)又可能會不一致，帶來業(yè)務(wù)上的挑戰(zhàn)，用戶也是難以接受的。

業(yè)務(wù)為用戶服務(wù)，技術(shù)為業(yè)務(wù)服務(wù)。

所以，為了權(quán)衡數(shù)據(jù)的并發(fā)問題和用戶體驗(yàn)，我們只允許在主節(jié)點(diǎn)上寫入數(shù)據(jù)，從節(jié)點(diǎn)上讀取數(shù)據(jù)。

不理解分布式一致性的同學(xué)可以看我之前的這篇文章：深入淺出：分布式、CAP和BASE理論

2）易于擴(kuò)展

我們都知道，大部分使用 Redis 的業(yè)務(wù)都是讀多寫少的。所以，我們可以根據(jù)業(yè)務(wù)量的規(guī)模來確定掛載幾個從節(jié)點(diǎn) Slave，當(dāng)緩存數(shù)據(jù)增大時，我們可以很方便的擴(kuò)展從節(jié)點(diǎn)的數(shù)量，實(shí)現(xiàn)彈性擴(kuò)展。

同時，讀寫分離還可以實(shí)現(xiàn)數(shù)據(jù)備份和負(fù)載均衡，從而提高可靠性和性能。

3）高可用保障

不僅如此，Redis 還可以手動切換主從節(jié)點(diǎn)，來做故障隔離和恢復(fù)。這樣，無論主節(jié)點(diǎn)或者從節(jié)點(diǎn)宕機(jī)，其他節(jié)點(diǎn)依然可以保證服務(wù)的正常運(yùn)行。

3. 主從復(fù)制實(shí)現(xiàn)

3.1 開啟主從復(fù)制

要開啟主從復(fù)制，我們需要用到 replicaof 命令。

當(dāng)我們確定好主節(jié)點(diǎn)的 IP 地址和端口號，在從庫執(zhí)行 replicaof <masterIP> <masterPort> 這個命令，就可以開啟主從復(fù)制。

注意，在 Redis5.0 之前，該命令為 slaveof

開啟主從復(fù)制后，應(yīng)用層采用讀寫分離，所有的寫操作在主節(jié)點(diǎn)進(jìn)行，所有讀操作在從節(jié)點(diǎn)進(jìn)行。

主從節(jié)點(diǎn)會保持?jǐn)?shù)據(jù)的最終一致性：主庫更新數(shù)據(jù)后，會同步給從庫。

3.2 主從復(fù)制過程

那主從庫同步什么時候開始和結(jié)束呢？

是一次性傳輸還是分批次寫入？Redis 主從節(jié)點(diǎn)在同步過程中網(wǎng)絡(luò)中斷了，沒傳輸完成的怎么辦？

帶著這些疑問我們來分析下，首先，Redis 第一次數(shù)據(jù)同步時分 3 個階段。

1）建立連接，請求數(shù)據(jù)同步

主從節(jié)點(diǎn)建立連接，從庫請求數(shù)據(jù)同步。

從服務(wù)器從 replicaof 配置項(xiàng)中獲取主節(jié)點(diǎn)的 IP 和 Port，然后進(jìn)行連接。

連接成功后，從服務(wù)器會向主服務(wù)器發(fā)送 PSYNC 命令，表示要進(jìn)行同步。同時，命令中包含 runID 和 offset 兩個關(guān)鍵字段。

• runID：每個 Redis 實(shí)例的唯一標(biāo)識，當(dāng)主從復(fù)制進(jìn)行時，該值為 Redis 主節(jié)點(diǎn)實(shí)例的ID。由于首次同步時還不知道主庫的實(shí)例ID，所以該值第一次為 ?
• offset：從庫數(shù)據(jù)同步的偏移量，當(dāng)?shù)谝淮螐?fù)制時，該值為 -1，表示全量復(fù)制

主服務(wù)器收到 PSYNC 命令后，會創(chuàng)建一個專門用于復(fù)制的后臺線程（replication thread），然后記錄從節(jié)點(diǎn)的 offset 參數(shù)并開始進(jìn)行 RDB 同步。

2）RDB 同步

主庫生成 RDB 文件，同步給從庫。

當(dāng)從服務(wù)器連接到主服務(wù)器后，主服務(wù)器會將自己的數(shù)據(jù)發(fā)送給從服務(wù)器，這個過程叫做全量復(fù)制。主服務(wù)器會執(zhí)行 bgsave 命令，然后 fork 出一個子進(jìn)程來遍歷自己的數(shù)據(jù)集并生成一個 RDB 文件，將這個文件發(fā)送給從服務(wù)器。

在這期間，為了保證 Redis 的高性能，主節(jié)點(diǎn)的主進(jìn)程不會被阻塞，依舊對外提供服務(wù)并接收數(shù)據(jù)寫入緩沖區(qū)中。

從服務(wù)器接收到 RDB 文件后，會清空自身數(shù)據(jù)，然后加載這個文件，將自己的數(shù)據(jù)集替換成主服務(wù)器的數(shù)據(jù)集。

3）命令同步

在第一次同步過程中，由于是全量同步，所以用時可能比較長，這期間主庫依舊會寫入新數(shù)據(jù)。

但是，在數(shù)據(jù)同步一開始就生成的 RDB 文件中顯然是沒有這部分新增數(shù)據(jù)的，所以第一次數(shù)據(jù)同步后需要再發(fā)送一次這部分新增數(shù)據(jù)。

這樣，主服務(wù)器需要在發(fā)送完 RDB 文件后，將期間的寫操作重新發(fā)送給從服務(wù)器，以保證從服務(wù)器的數(shù)據(jù)集與主服務(wù)器保持一致。

3.3 增量同步

1）命令傳播

在完成全量復(fù)制后，主從服務(wù)器之間會保持一個 TCP 連接，主服務(wù)器會將自己的寫操作發(fā)送給從服務(wù)器，從服務(wù)器執(zhí)行這些寫操作，從而保持?jǐn)?shù)據(jù)一致性，這個過程也稱為基于長連接的命令傳播（command propagation）。

增量復(fù)制的數(shù)據(jù)是異步復(fù)制的，但通過記錄寫操作，主從服務(wù)器之間的數(shù)據(jù)最終會達(dá)到一致狀態(tài)。

2）網(wǎng)絡(luò)斷開后數(shù)據(jù)同步

命令傳播的過程中，由于網(wǎng)絡(luò)抖動或故障導(dǎo)致連接斷開，此時主節(jié)點(diǎn)上新的寫命令將無法同步到從庫。

即便是抖動瞬間又恢復(fù)網(wǎng)絡(luò)連接，但 TCP 連接已經(jīng)斷開，所以數(shù)據(jù)需要重新同步。

從 Redis 2.8 開始，從庫已支持增量同步，只會把斷開的時候沒有發(fā)生的寫命令，同步給從庫。

詳細(xì)過程如下：

1. 網(wǎng)絡(luò)恢復(fù)后，從庫攜帶之前主庫返回的 runid，還有復(fù)制的偏移量 offset 發(fā)送 psync runid offset 命令給主庫，請求數(shù)據(jù)同步；
2. 主庫收到命令后，核查 runid 和 offset，確認(rèn)沒問題將響應(yīng) continue 命令；
3. 主庫發(fā)送網(wǎng)絡(luò)斷開期間的寫命令，從庫接收命令并執(zhí)行。

這時，有細(xì)心的小伙伴可能要問了，網(wǎng)絡(luò)斷開后，主庫怎么知道哪些數(shù)據(jù)是新寫入的呢？

這是個好問題，接下來我們詳細(xì)說明一下。

3）增量復(fù)制的關(guān)鍵

Master 在執(zhí)行寫操作時，會將這些命令記錄在 repl_backlog_buffer （復(fù)制積壓緩沖區(qū)）里面，并使用 master_repl_offset 記錄寫入的位置偏移量。

而從庫在執(zhí)行同步的寫命令后，也會用 slave_repl_offset 記錄寫入的位置偏移量。正常情況下，從庫會和主庫的偏移量保持一致。

但是，當(dāng)網(wǎng)絡(luò)斷開后，主庫繼續(xù)寫入，而從庫沒有收到新的同步命令，所以偏移量就停止了。所以，master_repl_offset 會大于 slave_repl_offset。

注意：主從庫實(shí)現(xiàn)增量復(fù)制時，都是在 repl_backlog_buffer 緩沖區(qū)上進(jìn)行。

網(wǎng)絡(luò)斷開前后，主從庫的同步圖如下：

repl_backlog_buffer 復(fù)制積壓緩沖區(qū)是一個環(huán)形緩沖區(qū)，如果緩沖區(qū)慢了（比如超過 1024），則會從頭覆蓋掉前面的內(nèi)容。

所以，當(dāng)網(wǎng)絡(luò)恢復(fù)以后，主節(jié)點(diǎn)只需將 master_repl_offset 和 slave_repl_offset 之間的內(nèi)容同步給從庫即可（圖中 256~512 這部分?jǐn)?shù)據(jù)）。

需要注意的是，主庫的積壓緩沖區(qū)默認(rèn)為 1M，如果從庫網(wǎng)絡(luò)斷開太久，緩沖區(qū)之前的內(nèi)容已經(jīng)被覆蓋，這時主從的數(shù)據(jù)復(fù)制就只能采取全量同步了。

所以我們需要根據(jù)業(yè)務(wù)量和實(shí)際情況來設(shè)置 repl_backlog_buffer 的值。

4. 小結(jié)

面讓架構(gòu)易于擴(kuò)展，另一方面防止單體故障：當(dāng)主庫掛了，可以立即拉起從庫，不至于讓業(yè)務(wù)停滯太久。

而首次主從復(fù)制包括建立連接，RDB 同步和命令同步三個階段。

為了保證同步的效率，除了第一次需要全量同步以外，例如當(dāng)主從節(jié)點(diǎn)斷連后，則只需要增量同步，這是由主從庫的復(fù)制偏移量以及主庫的 repl_backlog_buffer 復(fù)制積壓緩沖區(qū)來控制的。