摘要：前言只有光頭才能變強好的，今天我們要上鉑金段位了，如果還沒經歷過青銅和白銀和黃金階段的，可以先去蹭蹭經驗再回來從零單排學青銅從零單排學白銀從零單排學黃金這篇文章主要講的是主從復制。

只有光頭才能變強

好的，今天我們要上鉑金段位了，如果還沒經歷過青銅和白銀和黃金階段的，可以先去蹭蹭經驗再回來：

從零單排學Redis【青銅】

從零單排學Redis【白銀】

從零單排學Redis【黃金】

這篇文章主要講的是Redis主從復制。因為Redis集群的知識點有點多，所以鉑金上分得要好幾篇~

文本力求簡單講清每個知識點，希望大家看完能有所收獲

Redis也跟關系型數據(MySQL)一樣，如果有過多請求還是撐不住的。

因為Redis如果只有一臺服務器的話，那隨著請求越來越多：

Redis的內存是有限的，可能放不下那么多的數據

單臺Redis支持的并發量也是有限的。

萬一這臺Redis掛了，所有的請求全走關系數據庫了，那就更炸了。

顯然，出現的上述問題是因為一臺Redis服務器不夠，所以多搞幾臺Redis服務器就可以了

為了實現我們服務的高可用性，可以將這幾臺Redis服務器做成是主從來進行管理

tip:Redis作者已將Master/Slave架構改名為Master/Replica

下面我們來看看Redis的主從架構特點：

主服務器負責接收寫請求

從服務器負責接收讀請求

從服務器的數據由主服務器復制過去。主從服務器的數據是一致的

主從架構的好處：

讀寫分離(主服務器負責寫，從服務器負責讀)

高可用(某一臺從服務器掛了，其他從服務器還能繼續接收請求，不影響服務)

處理更多的并發量(每臺從服務器都可以接收讀請求，讀QPS就上去了)

主從架構除了上面的形式，也有下面這種的(只不過用得比較少)：

主從架構的特點之一：主服務器和從服務器的數據是一致的。

因為主服務器是能接收寫請求的，主服務器處理完寫請求，會做什么來保證主從數據的一致性呢？如果主從服務器斷開了，過一陣子才重連，又會怎么處理呢？下面將會了解到這些細節~

在Redis中，用戶可以通過執行SALVEOF命令或者設置salveof選項，讓一個服務器去復制(replicate)另一個服務器，我們稱呼被復制的服務器為主服務器(master)，而對主服務器進行復制的服務器則被稱為從服務器(salve)

復制功能分為兩個操作：

同步(sync)

將從服務器的數據庫狀態更新至主服務器的數據庫狀態

命令傳播(command propagate)

主服務器的數據庫狀態被修改，導致主從服務器的數據庫狀態不一致，讓主從服務器的數據庫狀態重新回到一致狀態。

從服務器對主服務器的同步又可以分為兩種情況：

初次同步：從服務器沒有復制過任何的主服務器，或者從服務器要復制的主服務器跟上次復制的主服務器不一樣。

斷線后同步：處于命令傳播階段的主從服務器因為網絡原因中斷了復制，從服務器通過自動重連重新連接主服務器，并繼續復制主服務器

在Redis2.8以前，斷線后復制這部分其實缺少的只是部分的數據，但是要讓主從服務器重新執行SYNC命令，這樣的做法是非常低效的。(因為執行SYNC命令是把所有的數據再次同步，而不是只同步丟失的數據)

接下來我們來詳細看看Redis2.8以后復制功能是怎么實現的：

首先我們來看一下前置的工作：

從服務器設置主服務器的IP和端口

建立與主服務器的Socket連接

發送PING命令(檢測Socket讀寫是否正常與主服務器的通信狀況)

身份驗證(看有沒有設置對應的驗證配置)

從服務器給主服務器發送端口的信息，主服務器記錄監聽的端口

前面也提到了，Redis2.8之前，斷線后同步會重新執行SYNC命令，這是非常低效的。下面我們來看一下Redis2.8之后是怎么進行同步的。

Redis從2.8版本開始，使用PSYNC命令來替代SYNC命令執行復制時同步的操作。

PSYNC命令具有完整重同步和部分重同步兩種模式(其實就跟上面所說的初次復制和斷線后復制差不多個意思)。

下面先來看看完整重同步是怎么實現的：

從服務器向主服務器發送PSYNC命令

收到PSYNC命令的主服務器執行BGSAVE命令，在后臺生成一個RDB文件。并用一個緩沖區來記錄從現在開始執行的所有寫命令。

當主服務器的BGSAVE命令執行完后，將生成的RDB文件發送給從服務器，從服務器接收和載入RBD文件。將自己的數據庫狀態更新至與主服務器執行BGSAVE命令時的狀態。

主服務器將所有緩沖區的寫命令發送給從服務器，從服務器執行這些寫命令，達到數據最終一致性。

接下來我們來看看部分重同步，部分重同步可以讓我們斷線后重連只需要同步缺失的數據(而不是Redis2.8之前的同步全部數據)，這是符合邏輯的！

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

主從服務器的復制偏移量

主服務器的復制積壓緩沖區

服務器運行的ID(run ID)

首先我們來解釋一下上面的名詞：

復制偏移量：執行復制的雙方都會分別維護一個復制偏移量

主服務器每次傳播N個字節，就將自己的復制偏移量加上N

從服務器每次收到主服務器的N個字節，就將自己的復制偏移量加上N

通過對比主從復制的偏移量，就很容易知道主從服務器的數據是否處于一致性的狀態！

那斷線重連以后，從服務器向主服務器發送PSYNC命令，報告現在的偏移量是36，那么主服務器該對從服務器執行完整重同步還是部分重同步呢？？這就交由復制積壓緩沖區來決定。

當主服務器進行命令傳播時，不僅僅會將寫命令發送給所有的從服務器，還會將寫命令入隊到復制積壓緩沖區里面(這個大小可以調的)。如果復制積壓緩沖區存在丟失的偏移量的數據，那就執行部分重同步，否則執行完整重同步。

服務器運行的ID(run ID)實際上就是用來比對ID是否相同。如果不相同，則說明從服務器斷線之前復制的主服務器和當前連接的主服務器是兩臺服務器，這就會進行完整重同步。

所以流程大概如此：

當完成了同步之后，主從服務器就會進入命令傳播階段。這時主服務器只要將自己的寫命令發送給從服務器，而從服務器接收并執行主服務器發送過來的寫命令，就可以保證主從服務器一直保持數據一致了！

在命令傳播階段，從服務器默認會以每秒一次的頻率，向服務器發送命令REPLCONF ACK 其中replication_offset是從服務器當前的復制偏移量

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

檢測主從服務器的網絡狀態

輔助實現min-slaves選項

檢測命令丟失

畫了好久好久的圖，終于寫完啦。

拋個問題：如果從服務器掛了，沒關系，我們一般會有多個從服務器，其他的請求可以交由沒有掛的從服務器繼續處理。如果主服務器掛了，怎么辦？因為我們的寫請求由主服務器處理，只有一臺主服務器，那就無法處理寫請求了？

問題留到下篇解決~~

參考資料：

《Redis設計與實現》

《Redis實戰》

如果你覺得我寫得還不錯，了解一下：

堅持原創的技術公眾號：Java3y?；貜?1 加入Java交流群

文章的目錄導航(精美腦圖+海量視頻資源)：https://github.com/ZhongFuCheng3y/3y