一文讓你明白Redis主從同步

今天想和你們分享有關 Redis 主從同步（也稱「複製」）的內容。

咱們知道，當有多臺 Redis 服務器時，確定就有一臺主服務器和多臺從服務器。通常來講，主服務器進行寫操做，從服務器進行讀操做。

那麼這裏有存在一個問題：從服務器如何和主服務器進行數據同步的呢？

這個問題，就是經過今天的內容：主從同步來解決的。

文章內容依舊比較幹，建議你們靜下心來專心看，文末會給你們作個簡單總結概括。

1. 如何進行主從同步

假如，如今有 2 臺 Redis 服務器，地址分別是 127.0.0.1:6379 和 127.0.0.1:12345

咱們在 127.0.0.1:12345 的客戶端輸入命令：

127.0.0.1:12345> SLAVEOF 127.0.0.6379

如此 127.0.0.1:12345 服務器就會去複製 127.0.0.1:6379 的數據。即前者是從服務器，後者爲主服務器。

除了以上方式進行復制以外，還能夠經過配置文件中的 slaveof 選項進行設置。

可能，求知慾爆棚的你會想知道，Redis 是怎麼進行主從同步的？

ok，下面咱們繼續瞭解一下。

2. 主從同步的實現過程

主從同步分爲 2 個步驟：同步和命令傳播

• 同步：將從服務器的數據庫狀態更新成主服務器當前的數據庫狀態。（數據庫狀態在這篇文章開頭有提到是什麼意思，不清楚的小夥伴能夠先看下：《持久化》）
• 命令傳播：當主服務器數據庫狀態被修改後，致使主從服務器數據庫狀態不一致，此時須要讓主從數據同步到一致的過程。

上面就是主從同步 2 個步驟的做用，下面我打算稍微細說這兩個步驟的實現過程。

這裏須要提早說明一下：在 Redis 2.8 版本以前，進行主從複製時必定會順序執行上述兩個步驟，而從 2.8 開始則可能只須要執行命令傳播便可。在下文也會解釋爲何會這樣？

2.1 同步

從服務器對主服務的同步操做，須要經過 sync 命令來實現，如下是 sync 命令的執行步驟：

1. 從服務器向主服務器發送 sync 命令
2. 收到 sync 命令後，主服務器執行 bgsave 命令，用來生成 rdb 文件，並在一個緩衝區中記錄從如今開始執行的寫命令。
3. bgsave 執行完成後，將生成的 rdb 文件發送給從服務器，用來給從服務器更新數據
4. 主服務器再將緩衝區記錄的寫命令發送給從服務器，從服務器執行完這些寫命令後，此時的數據庫狀態便和主服務器一致了。

用圖表示就是這樣的：

2.2 命令傳播

通過同步操做，此時主從的數據庫狀態其實已經一致了，但這種一致的狀態的並非一成不變的。

在完成同步以後，也許主服務器立刻就接受到了新的寫命令，執行完該命令後，主從的數據庫狀態又不一致。

爲了再次讓主從數據庫狀態一致，主服務器就須要向從服務器執行命令傳播操做 ，即把剛纔形成不一致的寫命令，發送給從服務器去執行。從服務器執行完成以後，主從數據庫狀態就又恢復一致了。

這裏插播一個疑問：

不知道有沒有的讀者以爲，當發生上述不一致的狀況後，Redis 再執行同步操做不就 ok 了嗎？

從效果上來講，的確是能夠恢復同步，但其實沒有必要。緣由是實現同步的 sync 命令是一個很是消耗資源的操做，看完下圖的說明，相信你確定理解的。

既然同步是一個很是消耗資源的操做，那 Redis 有沒有什麼優化方法呢？答案固然是有的。

2.3 優化版同步操做

還記得上面說的內容嗎 —— 2.8 版本開始，進行主從同步可能只須要執行命令傳播便可。這個也是由於 sync 比較耗資源，從而採起的優化。

那何時能夠這麼作呢？咱們先看下前提條件：

主從同步實際分 2 種狀況：

• 初次複製：從服務器第一次複製當前主服務器（PS：主服務器是有可能更換的）
• 斷線後重複製：處於命令傳播階段的主從服務器，由於網絡問題而中斷複製，從服務器經過自動重連，從新鏈接上主服務器並繼續複製。

在斷線後重複製的狀況下，在 2.8 版本以前，會再次執行同步（sync 命令）和命令傳播。

若是說，在斷線期間，主服務器（已有上萬鍵值對）只執行了幾個寫命令，爲了讓從服務器彌補這幾個命令，卻要從新執行 sync 來生成新的 rdb 文件，這也是很是低效的。

爲了解決這個問題，2.8 開始就使用 psync 命令來代替 sync 命令去執行同步操做。

psync 具備完整重同步和部分重同步兩種模式：

• 完整重同步：用於初次複製狀況，執行過程同 sync，在這不贅述了。
• 部分重同步：用於斷線後重複製狀況，若是知足必定條件，主服務器只須要將斷線期間執行的寫命令發送給從服務器便可。

所以很明顯，當主從同步出現斷線後重複製的狀況，psync 的部分重同步模式能夠解決 sync 的低效狀況。

上面的介紹中，出現了「知足必定條件」，那又是鬼什麼條件呢？—— 其實就是一個偏移量的比較，具體能夠繼續往下看。

2.4 部分重同步的實現

部分重同步功能由如下 3 部分組成：

• 主從服務器的複製偏移量
• 主服務器的複製積壓緩衝區
• 服務器的運行 id（run id）

2.4.1 複製偏移量

執行復制的主從服務器都會分別維護各自的複製偏移量：

• 主服務器每次向從服務器傳播 n 個字節數據時，都會將本身的複製偏移量加 n。
• 從服務器接受主服務器傳來的數據時，也會將本身的複製偏移量加 n

舉個例子：

若當前主服務器的複製偏移量爲 10000，此時向從服務器傳播 30 個字節數據，結束後複製偏移量爲 10030。

這時，從服務器還沒接收這 30 個字節數據就斷線了，而後從新鏈接上以後，該從服務器的複製偏移量依舊爲 10000，說明主從數據不一致，此時會向主服務器發送 psync 命令。

那麼主服務器應該對從服務器執行完整重同步仍是部分重同步呢？若是執行部分重同步的話，主服務器又如何知道同步哪些數據給從服務器呢？

如下答案都和複製積壓緩衝區有關

2.4.2 複製積壓緩衝區

首先，複製積壓緩衝區是一個固定長度，先進先出的隊列，默認 1MB。

當主服務器進行命令傳播時，不只會將命令發送給從服務器，還會發送給這個緩衝區。

所以複製積壓緩衝區的構造是這樣的：

當從服務器向主服務器發送 psync 命令時，還須要將本身的複製偏移量帶上，主服務器就能夠經過這個複製偏移量和複製積壓緩衝區的偏移量進行對比。

若複製積壓緩衝區存在從服務器的複製偏移量 + 1 後的數據，則進行部分重同步，不然進行完整重同步。

2.4.3 run id

運行 id 是在進行初次複製時，主服務器將會將本身的運行 id 發送給從服務器，讓其保存起來。

當從服務器斷線重連後，從服務器會將這個運行 id 發送給剛鏈接上的主服務器。

若當前服務器的運行 id 與之相同，說明從服務器斷線前複製的服務器就是當前服務器，主服務器能夠嘗試執行部分同步；若不一樣則說明從服務器斷線前複製的服務器不是當前服務器，主服務器直接執行完整重同步。

花了不少筆墨，終於把部分重同步的實現寫完了，最後補充一個輔助功能

2.5 心跳檢測

剛纔提到，主從同步有同步和命令傳播 2 個步驟。

當完成了同步以後，主從服務器就會進入命令傳播階段，此時從服務器會以每秒 1 次的頻率，向主服務器發送命令：REPLCONF ACK <replication_offset> 其中 replication_offset 是從服務器當前的複製偏移量

發送這個命令主要有三個做用：

• 檢測主從服務器的網絡狀態
• 輔助實現 min-slaves 選項
• 檢測命令丟失（若丟失，主服務器會將丟失的寫命令從新發給從服務器）

3. 總結

終於寫完了最後內容，幾個小時又過去了，咱們來總結下本文內容吧：

• 發送 SLAVEOF 命令能夠進行主從同步，好比：SLAVEOF 127.0.0.6379

• 主從同步有同步和命令傳播 2 個步驟。

  • 同步：將從服務器的數據庫狀態更新成主服務器當前的數據庫狀態（一個消耗資源的操做）
  • 命令傳播：當主服務器數據庫狀態被修改後，致使主從服務器數據庫狀態不一致，此時須要讓主從數據同步到一致的過程

• 主從同步分初次複製和斷線後重複製兩種狀況

  • 從 2.8 版本開始，在出現斷線後重複製狀況時，主服務器會根據複製偏移量、複製積壓緩衝區和 run id，來肯定執行完整重同步仍是部分重同步
• 2.8 版本使用 psync 命令來代替 sync 命令去執行同步操做。目的是爲了解決同步（sync 命令）的低效操做

PS：本文原創發佈於微信公衆號「不僅Java」，堅持原創！後臺回覆如下關鍵字獲取經典必讀書籍：Java、MySQL、Redis、Linux、mq、數據結構、設計模式、編程思想、架構