[[408729]]

本文轉(zhuǎn)載自微信公眾號「小林coding」，作者小林coding。轉(zhuǎn)載本文請聯(lián)系小林coding公眾號。

大家好，我是小林哥。

又來圖解 Redis 啦。

我在前兩篇已經(jīng)給大家圖解了 AOF 和 RDB，這兩個持久化技術(shù)保證了即使在服務(wù)器重啟的情況下也不會丟失數(shù)據(jù)(或少量損失)。

不過，由于數(shù)據(jù)都是存儲在一臺服務(wù)器上，如果出事就完犢子了，比如：

• 如果服務(wù)器發(fā)生了宕機(jī)，由于數(shù)據(jù)恢復(fù)是需要點時間，那么這個期間是無法服務(wù)新的請求的;
• 如果這臺服務(wù)器的硬盤出現(xiàn)了故障，可能數(shù)據(jù)就都丟失了。

要避免這種單點故障，最好的辦法是將數(shù)據(jù)備份到其他服務(wù)器上，讓這些服務(wù)器也可以對外提供服務(wù)，這樣即使有一臺服務(wù)器出現(xiàn)了故障，其他服務(wù)器依然可以繼續(xù)提供服務(wù)。

多臺服務(wù)器要保存同一份數(shù)據(jù)，這里問題就來了。

這些服務(wù)器之間的數(shù)據(jù)如何保持一致性呢?數(shù)據(jù)的讀寫操作是否每臺服務(wù)器都可以處理?

Redis 提供了主從復(fù)制模式，來避免上述的問題。

這個模式可以保證多臺服務(wù)器的數(shù)據(jù)一致性，且主從服務(wù)器之間采用的是「讀寫分離」的方式。

主服務(wù)器可以進(jìn)行讀寫操作，當(dāng)發(fā)生寫操作時自動將寫操作同步給從服務(wù)器，而從服務(wù)器一般是只讀，并接受主服務(wù)器同步過來寫操作命令，然后執(zhí)行這條命令。

也就是說，所有的數(shù)據(jù)修改只在主服務(wù)器上進(jìn)行，然后將最新的數(shù)據(jù)同步給從服務(wù)器，這樣就使得主從服務(wù)器的數(shù)據(jù)是一致的。

同步這兩個字說的簡單，但是這個同步過程并沒有想象中那么簡單，要考慮的事情不是一兩個。

我們先來看看，主從服務(wù)器間的第一次同步是如何工作的?

第一次同步

多臺服務(wù)器之間要通過什么方式來確定誰是主服務(wù)器，或者誰是從服務(wù)器呢?

我們可以使用 replicaof(Redis 5.0 之前使用 slaveof)命令形成主服務(wù)器和從服務(wù)器的關(guān)系。

比如，現(xiàn)在有服務(wù)器 A 和 服務(wù)器 B，我們在服務(wù)器 B 上執(zhí)行下面這條命令：

# 服務(wù)器 B 執(zhí)行這條命令

replicaof <服務(wù)器 A 的 IP 地址> <服務(wù)器 A 的 Redis 端口號>

接著，服務(wù)器 B 就會變成服務(wù)器 A 的「從服務(wù)器」，然后與主服務(wù)器進(jìn)行第一次同步。

主從服務(wù)器間的第一次同步的過程可分為三個階段：

• 第一階段是建立鏈接、協(xié)商同步;
• 第二階段是主服務(wù)器同步數(shù)據(jù)給從服務(wù)器;
• 第三階段是主服務(wù)器發(fā)送新寫操作命令給從服務(wù)器。

為了讓你更清楚了解這三個階段，我畫了一張圖。

接下來，我在具體介紹每一個階段都做了什么。

第一階段：建立鏈接、協(xié)商同步

執(zhí)行了 replicaof 命令后，從服務(wù)器就會給主服務(wù)器發(fā)送 psync 命令，表示要進(jìn)行數(shù)據(jù)同步。

psync 命令包含兩個參數(shù)，分別是主服務(wù)器的 runID 和復(fù)制進(jìn)度 offset。

• runID，每個 Redis 服務(wù)器在啟動時都會自動生產(chǎn)一個隨機(jī)的 ID 來唯一標(biāo)識自己。當(dāng)從服務(wù)器和主服務(wù)器第一次同步時，因為不知道主服務(wù)器的 run ID，所以將其設(shè)置為 "?"。
• offset，表示復(fù)制的進(jìn)度，第一次同步時，其值為 -1。

主服務(wù)器收到 psync 命令后，會用 FULLRESYNC 作為響應(yīng)命令返回給對方。

并且這個響應(yīng)命令會帶上兩個參數(shù)：主服務(wù)器的 runID 和主服務(wù)器目前的復(fù)制進(jìn)度 offset。從服務(wù)器收到響應(yīng)后，會記錄這兩個值。

FULLRESYNC 響應(yīng)命令的意圖是采用全量復(fù)制的方式，也就是主服務(wù)器會把所有的數(shù)據(jù)都同步給從服務(wù)器。

所以，第一階段的工作時為了全量復(fù)制做準(zhǔn)備。

那具體怎么全量同步呀呢?我們可以往下看第二階段。

第二階段：主服務(wù)器同步數(shù)據(jù)給從服務(wù)器

接著，主服務(wù)器會執(zhí)行 bgsave 命令來生成 RDB 文件，然后把文件發(fā)送給從服務(wù)器。

從服務(wù)器收到 RDB 文件后，會先清空當(dāng)前的數(shù)據(jù)，然后載入 RDB 文件。

這里有一點要注意，主服務(wù)器生成 RDB 這個過程是不會阻塞主線程的，也就是說 Redis 依然可以正常處理命令。

但是這期間的寫操作命令并沒有記錄到剛剛生成的 RDB 文件中，這時主從服務(wù)器間的數(shù)據(jù)就不一致了。

那么為了保證主從服務(wù)器的數(shù)據(jù)一致性，主服務(wù)器會將在 RDB 文件生成后收到的寫操作命令，寫入到 replication buffer 緩沖區(qū)里。

第三階段：主服務(wù)器發(fā)送新寫操作命令給從服務(wù)器

在主服務(wù)器生成的 RDB 文件發(fā)送后，然后將 replication buffer 緩沖區(qū)里所記錄的寫操作命令發(fā)送給從服務(wù)器，然后從服務(wù)器重新執(zhí)行這些操作。

至此，主從服務(wù)器的第一次同步的工作就完成了。

命令傳播

主從服務(wù)器在完成第一次同步后，雙方之間就會維護(hù)一個 TCP 連接。

后續(xù)主服務(wù)器可以通過這個連接繼續(xù)將寫操作命令傳播給從服務(wù)器，然后從服務(wù)器執(zhí)行該命令，使得與主服務(wù)器的數(shù)據(jù)庫狀態(tài)相同。

而且這個連接是長連接的，目的是避免頻繁的 TCP 連接和斷開帶來的性能開銷。

上面的這個過程被稱為基于長連接的命令傳播，通過這種方式來保證第一次同步后的主從服務(wù)器的數(shù)據(jù)一致性。

分?jǐn)傊鞣?wù)器的壓力

在前面的分析中，我們可以知道主從服務(wù)器在第一次數(shù)據(jù)同步的過程中，主服務(wù)器會做兩件耗時的操作：生成 RDB 文件和傳輸 RDB 文件。

主服務(wù)器是可以有多個從服務(wù)器的，如果從服務(wù)器數(shù)量非常多，而且都與主服務(wù)器進(jìn)行全量同步的話，就會帶來兩個問題：

• 由于是通過 bgsave 命令來生成 RDB 文件的，那么主服務(wù)器就會忙于使用 fork() 創(chuàng)建子進(jìn)程，如果主服務(wù)器的內(nèi)存數(shù)據(jù)非大，在執(zhí)行 fork() 函數(shù)時是會阻塞主線程的，從而使得 Redis 無法正常處理請求;
• 傳輸 RDB 文件會占用主服務(wù)器的網(wǎng)絡(luò)帶寬，會對主服務(wù)器響應(yīng)命令請求產(chǎn)生影響。

這種情況就好像，剛創(chuàng)業(yè)的公司，由于人不多，所以員工都?xì)w老板一個人管，但是隨著公司的發(fā)展，人員的擴(kuò)充，老板慢慢就無法承擔(dān)全部員工的管理工作了。

要解決這個問題，老板就需要設(shè)立經(jīng)理職位，由經(jīng)理管理多名普通員工，然后老板只需要管理經(jīng)理就好。

Redis 也是一樣的，從服務(wù)器可以有自己的從服務(wù)器，我們可以把擁有從服務(wù)器的從服務(wù)器當(dāng)作經(jīng)理角色，它不僅可以接收主服務(wù)器的同步數(shù)據(jù)，自己也可以同時作為主服務(wù)器的形式將數(shù)據(jù)同步給從服務(wù)器，組織形式如下圖：

通過這種方式，主服務(wù)器生成 RDB 和傳輸 RDB 的壓力可以分?jǐn)偟匠洚?dāng)經(jīng)理角色的從服務(wù)器。

那具體怎么做到的呢?

其實很簡單，我們在「從服務(wù)器」上執(zhí)行下面這條命令，使其作為目標(biāo)服務(wù)器的從服務(wù)器：

replicaof <目標(biāo)服務(wù)器的IP> 6379

此時如果目標(biāo)服務(wù)器本身也是「從服務(wù)器」，那么該目標(biāo)服務(wù)器就會成為「經(jīng)理」的角色，不僅可以接受主服務(wù)器同步的數(shù)據(jù)，也會把數(shù)據(jù)同步給自己旗下的從服務(wù)器，從而減輕主服務(wù)器的負(fù)擔(dān)。

增量復(fù)制

主從服務(wù)器在完成第一次同步后，就會基于長連接進(jìn)行命令傳播。

可是，網(wǎng)絡(luò)總是不按套路出牌的嘛，說延遲就延遲，說斷開就斷開。

如果主從服務(wù)器間的網(wǎng)絡(luò)連接斷開了，那么就無法進(jìn)行命令傳播了，這時從服務(wù)器的數(shù)據(jù)就沒辦法和主服務(wù)器保持一致了，客戶端就可能從「從服務(wù)器」讀到舊的數(shù)據(jù)。

那么問題來了，如果此時斷開的網(wǎng)絡(luò)，又恢復(fù)正常了，要怎么繼續(xù)保證主從服務(wù)器的數(shù)據(jù)一致性呢?

在 Redis 2.8 之前，如果主從服務(wù)器在命令同步時出現(xiàn)了網(wǎng)絡(luò)斷開又恢復(fù)的情況，從服務(wù)器就會和主服務(wù)器重新進(jìn)行一次全量復(fù)制，很明顯這樣的開銷太大了，必須要改進(jìn)一波。

所以，從 Redis 2.8 開始，網(wǎng)絡(luò)斷開又恢復(fù)后，從主從服務(wù)器會采用增量復(fù)制的方式繼續(xù)同步，也就是只會把網(wǎng)絡(luò)斷開期間主服務(wù)器接收到的寫操作命令，同步給從服務(wù)器。

網(wǎng)絡(luò)恢復(fù)后的增量復(fù)制過程如下圖：

主要有三個步驟：

• 從服務(wù)器在恢復(fù)網(wǎng)絡(luò)后，會發(fā)送 psync 命令給主服務(wù)器，此時的 psync 命令里的 offset 參數(shù)不是 -1;
• 主服務(wù)器收到該命令后，然后用 CONTINUE 響應(yīng)命令告訴從服務(wù)器接下來采用增量復(fù)制的方式同步數(shù)據(jù);
• 然后主服務(wù)將主從服務(wù)器斷線期間，所執(zhí)行的寫命令發(fā)送給從服務(wù)器，然后從服務(wù)器執(zhí)行這些命令。

那么關(guān)鍵的問題來了，主服務(wù)器怎么知道要將哪些增量數(shù)據(jù)發(fā)送給從服務(wù)器呢?

答案藏在這兩個東西里：

• repl_backlog_buffer，是一個「環(huán)形」緩沖區(qū)，用于主從服務(wù)器斷連后，從中找到差異的數(shù)據(jù);
• replication offset，標(biāo)記上面那個緩沖區(qū)的同步進(jìn)度，主從服務(wù)器都有各自的偏移量，主服務(wù)器使用 master_repl_offset 來記錄自己「寫」到的位置，從服務(wù)器使用 slave_repl_offset 來記錄自己「讀」到的位置。

那repl_backlog_buffer 緩沖區(qū)是什么時候?qū)懭氲哪?

在主服務(wù)器進(jìn)行命令傳播時，不僅會將寫命令發(fā)送給從服務(wù)器，還會將寫命令寫入到 repl_backlog_buffer 緩沖區(qū)里，因此 這個緩沖區(qū)里會保存著最近傳播的寫命令。

網(wǎng)絡(luò)斷開后，當(dāng)從服務(wù)器重新連上主服務(wù)器時，從服務(wù)器會通過 psync 命令將自己的復(fù)制偏移量 slave_repl_offset 發(fā)送給主服務(wù)器，主服務(wù)器根據(jù)自己的 master_repl_offset 和 slave_repl_offset 之間的差距，然后來決定對從服務(wù)器執(zhí)行哪種同步操作：

• 如果判斷出從服務(wù)器要讀取的數(shù)據(jù)還在 repl_backlog_buffer 緩沖區(qū)里，那么主服務(wù)器將采用增量同步的方式;
• 相反，如果判斷出從服務(wù)器要讀取的數(shù)據(jù)已經(jīng)不存在

repl_backlog_buffer 緩沖區(qū)里，那么主服務(wù)器將采用全量同步的方式。

當(dāng)主服務(wù)器在 repl_backlog_buffer 中找到主從服務(wù)器差異(增量)的數(shù)據(jù)后，就會將增量的數(shù)據(jù)寫入到 replication buffer 緩沖區(qū)，這個緩沖區(qū)我們前面也提到過，它是緩存將要傳播給從服務(wù)器的命令。

repl_backlog_buffer 緩行緩沖區(qū)的默認(rèn)大小是 1M，并且由于它是一個環(huán)形緩沖區(qū)，所以當(dāng)緩沖區(qū)寫滿后，主服務(wù)器繼續(xù)寫入的話，就會覆蓋之前的數(shù)據(jù)。

因此，當(dāng)主服務(wù)器的寫入速度遠(yuǎn)超于從服務(wù)器的讀取速度，緩沖區(qū)的數(shù)據(jù)一下就會被覆蓋。

那么在網(wǎng)絡(luò)恢復(fù)時，如果從服務(wù)器想讀的數(shù)據(jù)已經(jīng)被覆蓋了，主服務(wù)器就會采用全量同步，這個方式比增量同步的性能損耗要大很多。

因此，為了避免在網(wǎng)絡(luò)恢復(fù)時，主服務(wù)器頻繁地使用全量同步的方式，我們應(yīng)該調(diào)整下 repl_backlog_buffer 緩沖區(qū)大小，盡可能的大一些，減少出現(xiàn)從服務(wù)器要讀取的數(shù)據(jù)被覆蓋的概率，從而使得主服務(wù)器采用增量同步的方式。

那 repl_backlog_buffer 緩沖區(qū)具體要調(diào)整到多大呢?

repl_backlog_buffer 最小的大小可以根據(jù)這面這個公式估算。

我來解釋下這個公式的意思：

• second 為從服務(wù)器斷線后重新連接上主服務(wù)器所需的平均 時間(以秒計算)。
• write_size_per_second 則是主服務(wù)器平均每秒產(chǎn)生的寫命令數(shù)據(jù)量大小。

舉個例子，如果主服務(wù)器平均每秒產(chǎn)生 1 MB 的寫命令，而從服務(wù)器斷線之后平均要 5 秒才能重新連接主服務(wù)器。

那么 repl_backlog_buffer 大小就不能低于 5 MB，否則新寫地命令就會覆蓋舊數(shù)據(jù)了。

當(dāng)然，為了應(yīng)對一些突發(fā)的情況，可以將 repl_backlog_buffer 的大小設(shè)置為此基礎(chǔ)上的 2 倍，也就是 10 MB。

關(guān)于 repl_backlog_buffer 大小修改的方法，只需要修改配置文件里下面這個參數(shù)項的值就可以。

repl-backlog-size 1mb 

總結(jié)

主從復(fù)制共有三種模式：全量復(fù)制、基于長連接的命令傳播、增量復(fù)制。

主從服務(wù)器第一次同步的時候，就是采用全量復(fù)制，此時主服務(wù)器會兩個耗時的地方，分別是生成 RDB 文件和傳輸 RDB 文件。為了避免過多的從服務(wù)器和主服務(wù)器進(jìn)行全量復(fù)制，可以把一部分從服務(wù)器升級為「經(jīng)理角色」，讓它也有自己的從服務(wù)器，通過這樣可以分?jǐn)傊鞣?wù)器的壓力。

第一次同步完成后，主從服務(wù)器都會維護(hù)著一個長連接，主服務(wù)器在接收到寫操作命令后，就會通過這個連接將寫命令傳播給從服務(wù)器，來保證主從服務(wù)器的數(shù)據(jù)一致性。

如果遇到網(wǎng)絡(luò)斷開，增量復(fù)制就可以上場了，不過這個還跟 repl_backlog_size 這個大小有關(guān)系。

如果它配置的過小，主從服務(wù)器網(wǎng)絡(luò)恢復(fù)時，可能發(fā)生「從服務(wù)器」想讀的數(shù)據(jù)已經(jīng)被覆蓋了，那么這時就會導(dǎo)致主服務(wù)器采用全量復(fù)制的方式。所以為了避免這種情況的頻繁發(fā)生，要調(diào)大這個參數(shù)的值，以降低主從服務(wù)器斷開后全量同步的概率。

參考資料

《Redis核心技術(shù)與實戰(zhàn)》

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

 

《Redis源碼分析》