redis主從復制原理的深入講解

前言

Redis持久化保證了即使redis服務重啟也不會丟失數(shù)據(jù)，因為redis服務重啟后會將硬盤上持久化的數(shù)據(jù)恢復到內存中，但是當redis服務器的硬盤損壞了可能會導致數(shù)據(jù)丟失，如果通過redis的主從復制機制就可以避免這種單點故障。

本文主要針對redis主從復制的原理進行了講解，分享出來供大家參考學習，下面話不多說了，來一起看看詳細的介紹吧

1.復制過程

2.數(shù)據(jù)間的同步

3.全量復制

4.部分復制

5.心跳

6.異步復制

1.復制過程

1. 從節(jié)點執(zhí)行 slaveof 命令。
2. 從節(jié)點只是保存了 slaveof 命令中主節(jié)點的信息，并沒有立即發(fā)起復制。
3. 從節(jié)點內部的定時任務發(fā)現(xiàn)有主節(jié)點的信息，開始使用 socket 連接主節(jié)點。
4. 連接建立成功后，發(fā)送 ping 命令，希望得到 pong 命令響應，否則會進行重連。
5. 如果主節(jié)點設置了權限，那么就需要進行權限驗證，如果驗證失敗，復制終止。
6. 權限驗證通過后，進行數(shù)據(jù)同步，這是耗時最長的操作，主節(jié)點將把所有的數(shù)據(jù)全部發(fā)送給從節(jié)點。
7. 當主節(jié)點把當前的數(shù)據(jù)同步給從節(jié)點后，便完成了復制的建立流程。接下來，主節(jié)點就會持續(xù)的把寫命令發(fā)送給從節(jié)點，保證主從數(shù)據(jù)一致性。

2.數(shù)據(jù)間的同步

上面說的復制過程，其中有一個步驟是“同步數(shù)據(jù)集”，這個就是現(xiàn)在講的“數(shù)據(jù)間的同步”。

redis 同步有 2 個命令：sync 和 psync，前者是 redis 2.8 之前的同步命令，后者是 redis 2.8 為了優(yōu)化 sync 新設計的命令。我們會重點關注 2.8 的 psync 命令。

psync 命令需要 3 個組件支持：

1. 主從節(jié)點各自復制偏移量
2. 主節(jié)點復制積壓緩沖區(qū)
3. 主節(jié)點運行 ID

主從節(jié)點各自復制偏移量：

1. 參與復制的主從節(jié)點都會維護自身的復制偏移量。
2. 主節(jié)點在處理完寫入命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計信息在 info replication 中的 masterreploffset 指標中。
3. 從節(jié)點每秒鐘上報自身的的復制偏移量給主節(jié)點，因此主節(jié)點也會保存從節(jié)點的復制偏移量。
4. 從節(jié)點在接收到主節(jié)點發(fā)送的命令后，也會累加自身的偏移量，統(tǒng)計信息在 info replication 中。
5. 通過對比主從節(jié)點的復制偏移量，可以判斷主從節(jié)點數(shù)據(jù)是否一致。

主節(jié)點復制積壓緩沖區(qū)：

1. 復制積壓緩沖區(qū)是一個保存在主節(jié)點的一個固定長度的先進先出的隊列，默認大小 1MB。
2.  這個隊列在 slave 連接是創(chuàng)建。這時主節(jié)點響應寫命令時，不但會把命令發(fā)送給從節(jié)點，也會寫入復制緩沖區(qū)。
3. 他的作用就是用于部分復制和復制命令丟失的數(shù)據(jù)補救。通過 info replication 可以看到相關信息。

主節(jié)點運行 ID：

1. 每個 redis 啟動的時候，都會生成一個 40 位的運行 ID。
2. 運行 ID 的主要作用是用來識別 Redis 節(jié)點。如果使用 ip+port 的方式，那么如果主節(jié)點重啟修改了 RDB/AOF 數(shù)據(jù)，從節(jié)點再基于偏移量進行復制將是不安全的。所以，當運行 id 變化后，從節(jié)點將進行全量復制。也就是說，redis 重啟后，默認從節(jié)點會進行全量復制。

如果在重啟時不改變運行 ID 呢？

1. 可以通過 debug reload 命令重新加載 RDB 并保持運行 ID 不變，從而有效的避免不必要的全量復制。
2. 缺點是：debug reload 命令會阻塞當前 Redis 節(jié)點主線程，因此對于大數(shù)據(jù)量的主節(jié)點或者無法容忍阻塞的節(jié)點，需要謹慎使用。一般通過故障轉移機制可以解決這個問題。

psync 命令的使用方式：

　　命令格式為psync{runId}{offset}

　　runId：從節(jié)點所復制主節(jié)點的運行 id

　　offset：當前從節(jié)點已復制的數(shù)據(jù)偏移量

psync 執(zhí)行流程：

流程說明：

從節(jié)點發(fā)送 psync 命令給主節(jié)點，runId 就是目標主節(jié)點的 ID，如果沒有默認為 -1，offset 是從節(jié)點保存的復制偏移量，如果是第一次復制則為 -1.

主節(jié)點會根據(jù) runid 和 offset 決定返回結果：

1. 如果回復 +FULLRESYNC {runId} {offset} ，那么從節(jié)點將觸發(fā)全量復制流程。
2. 如果回復 +CONTINUE，從節(jié)點將觸發(fā)部分復制。
3. 如果回復 +ERR，說明主節(jié)點不支持 2.8 的 psync 命令，將使用 sync 執(zhí)行全量復制。

到這里，數(shù)據(jù)之間的同步就講的差不多了，篇幅還是比較長的。主要是針對 psync 命令相關之間的介紹。

3.全量復制

全量復制是 Redis 最早支持的復制方式，也是主從第一次建立復制時必須經(jīng)歷的的階段。觸發(fā)全量復制的命令是 sync 和 psync。之前說過，這兩個命令的分水嶺版本是 2.8，redis 2.8 之前使用 sync 只能執(zhí)行全量不同，2.8 之后同時支持全量同步和部分同步。

流程如下：

發(fā)送 psync 命令（spync ？ -1）

主節(jié)點根據(jù)命令返回 FULLRESYNC

從節(jié)點記錄主節(jié)點 ID 和 offset

1. 發(fā)送 psync 命令（spync ？ -1）
2. 主節(jié)點根據(jù)命令返回 FULLRESYNC
3. 從節(jié)點記錄主節(jié)點 ID 和 offset
4. 主節(jié)點 bgsave 并保存 RDB 到本地
5. 主節(jié)點發(fā)送 RBD 文件到從節(jié)點
6. 從節(jié)點收到 RDB 文件并加載到內存中
7. 主節(jié)點在從節(jié)點接受數(shù)據(jù)的期間，將新數(shù)據(jù)保存到“復制客戶端緩沖區(qū)”，當從節(jié)點加載 RDB 完畢，再發(fā)送過去。（如果從節(jié)點花費時間過長，將導致緩沖區(qū)溢出，最后全量同步失?。?/li>
8. 從節(jié)點清空數(shù)據(jù)后加載 RDB 文件，如果 RDB 文件很大，這一步操作仍然耗時，如果此時客戶端訪問，將導致數(shù)據(jù)不一致，可以使用配置slave-server-stale-data 關閉.
9. 從節(jié)點成功加載完 RBD 后，如果開啟了 AOF，會立刻做 bgrewriteaof。

以上加粗的部分是整個全量同步耗時的地方。

注意：

如過 RDB 文件大于 6GB，并且是千兆網(wǎng)卡，Redis 的默認超時機制（60 秒），會導致全量復制失敗?？梢酝ㄟ^調大 repl-timeout 參數(shù)來解決此問題。 Redis 雖然支持無盤復制，即直接通過網(wǎng)絡發(fā)送給從節(jié)點，但功能不是很完善，生產(chǎn)環(huán)境慎用。

4.部分復制

當從節(jié)點正在復制主節(jié)點時，如果出現(xiàn)網(wǎng)絡閃斷和其他異常，從節(jié)點會讓主節(jié)點補發(fā)丟失的命令數(shù)據(jù)，主節(jié)點只需要將復制緩沖區(qū)的數(shù)據(jù)發(fā)送到從節(jié)點就能夠保證數(shù)據(jù)的一致性，相比較全量復制，成本小很多。

1. 當從節(jié)點出現(xiàn)網(wǎng)絡中斷，超過了 repl-timeout 時間，主節(jié)點就會中斷復制連接。
2. 主節(jié)點會將請求的數(shù)據(jù)寫入到“復制積壓緩沖區(qū)”，默認 1MB。
3. 當從節(jié)點恢復，重新連接上主節(jié)點，從節(jié)點會將 offset 和主節(jié)點 id 發(fā)送到主節(jié)點。
4. 主節(jié)點校驗后，如果偏移量的數(shù)后的數(shù)據(jù)在緩沖區(qū)中，就發(fā)送 cuntinue 響應 —— 表示可以進行部分復制。
5. 主節(jié)點將緩沖區(qū)的數(shù)據(jù)發(fā)送到從節(jié)點，保證主從復制進行正常狀態(tài)。

5.心跳

主從節(jié)點在建立復制后，他們之間維護著長連接并彼此發(fā)送心跳命令。

心跳的關鍵機制如下：

1. 中從都有心跳檢測機制，各自模擬成對方的客戶端進行通信，通過 client list 命令查看復制相關客戶端信息，主節(jié)點的連接狀態(tài)為 flags = M，從節(jié)點的連接狀態(tài)是 flags = S。
2. 主節(jié)點默認每隔 10 秒對從節(jié)點發(fā)送 ping 命令，可修改配置 repl-ping-slave-period 控制發(fā)送頻率。
3. 從節(jié)點在主線程每隔一秒發(fā)送 replconf ack{offset} 命令，給主節(jié)點上報自身當前的復制偏移量。
4. 主節(jié)點收到 replconf 信息后，判斷從節(jié)點超時時間，如果超過 repl-timeout 60 秒，則判斷節(jié)點下線。

注意：

為了降低主從延遲，一般把 redis 主從節(jié)點部署在相同的機房/同城機房，避免網(wǎng)絡延遲帶來的網(wǎng)絡分區(qū)造成的心跳中斷等情況。

6.異步復制

主節(jié)點不但負責數(shù)據(jù)讀寫，還負責把寫命令同步給從節(jié)點，寫命令的發(fā)送過程是異步完成，也就是說主節(jié)點處理完寫命令后立即返回客戶度，并不等待從節(jié)點復制完成。

異步復制的步驟很簡單，如下：

1. 主節(jié)點接受處理命令。
2. 主節(jié)點處理完后返回響應結果 。
3. 對于修改命令，異步發(fā)送給從節(jié)點，從節(jié)點在主線程中執(zhí)行復制的命令。

總結

本文主要分析了 Redis 的復制原理，包括復制過程，數(shù)據(jù)之間的同步，全量復制的流程，部分復制的流程，心跳設計，異步復制流程。其中，可以看出，RDB 數(shù)據(jù)之間的同步非常耗時。所以，Redis 在 2.8 版本退出了類似增量復制的 psync 命令，當 Redis 主從直接發(fā)生了網(wǎng)絡中斷，不會進行全量復制，而是將數(shù)據(jù)放到緩沖區(qū)（默認 1MB）里，在通過主從之間各自維護復制 offset 來判斷緩存區(qū)的數(shù)據(jù)是否溢出，如果沒有溢出，只需要發(fā)送緩沖區(qū)數(shù)據(jù)即可，成本很小，反之，則要進行全量復制，因此，控制緩沖區(qū)大小非常的重要。

好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。