今天想和大家分享有關 Redis 主從同步（也稱「復制」）的內(nèi)容。
我們知道，當有多臺 Redis 服務器時，肯定就有一臺主服務器和多臺從服務器。一般來說，主服務器進行寫操作，從服務器進行讀操作。
那么這里有存在一個問題：從服務器如何和主服務器進行數(shù)據(jù)同步的呢？
這個問題，就是通過今天的內(nèi)容：主從同步來解決的。
文章內(nèi)容依舊比較干，建議大家靜下心來專心看，文末會給大家做個簡單總結(jié)歸納。
1. 如何進行主從同步
假如，現(xiàn)在有 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 的數(shù)據(jù)。即前者是從服務器，后者為主服務器。
除了以上方式進行復制之外，還可以通過配置文件中的 slaveof 選項進行設置。
可能，求知欲爆棚的你會想知道，Redis 是怎么進行主從同步的？
ok，下面我們繼續(xù)了解一下。
2. 主從同步的實現(xiàn)過程
主從同步分為 2 個步驟：同步和命令傳播
- 同步：將從服務器的數(shù)據(jù)庫狀態(tài)更新成主服務器當前的數(shù)據(jù)庫狀態(tài)。（數(shù)據(jù)庫狀態(tài)在這篇文章開頭有提到是什么意思，不清楚的小伙伴可以先看下：《持久化》）
- 命令傳播：當主服務器數(shù)據(jù)庫狀態(tài)被修改后，導致主從服務器數(shù)據(jù)庫狀態(tài)不一致，此時需要讓主從數(shù)據(jù)同步到一致的過程。
上面就是主從同步 2 個步驟的作用，下面我打算稍微細說這兩個步驟的實現(xiàn)過程。
這里需要提前說明一下：在 Redis 2.8 版本之前，進行主從復制時一定會順序執(zhí)行上述兩個步驟，而從 2.8 開始則可能只需要執(zhí)行命令傳播即可。在下文也會解釋為什么會這樣？
2.1 同步
從服務器對主服務的同步操作，需要通過 sync 命令來實現(xiàn)，以下是 sync 命令的執(zhí)行步驟：
- 從服務器向主服務器發(fā)送 sync 命令
- 收到 sync 命令后，主服務器執(zhí)行 bgsave 命令，用來生成 rdb 文件，并在一個緩沖區(qū)中記錄從現(xiàn)在開始執(zhí)行的寫命令。
- bgsave 執(zhí)行完成后，將生成的 rdb 文件發(fā)送給從服務器，用來給從服務器更新數(shù)據(jù)
- 主服務器再將緩沖區(qū)記錄的寫命令發(fā)送給從服務器，從服務器執(zhí)行完這些寫命令后，此時的數(shù)據(jù)庫狀態(tài)便和主服務器一致了。
用圖表示就是這樣的：
2.2 命令傳播
經(jīng)過同步操作，此時主從的數(shù)據(jù)庫狀態(tài)其實已經(jīng)一致了，但這種一致的狀態(tài)的并不是一成不變的。
在完成同步之后，也許主服務器馬上就接受到了新的寫命令，執(zhí)行完該命令后，主從的數(shù)據(jù)庫狀態(tài)又不一致。
為了再次讓主從數(shù)據(jù)庫狀態(tài)一致，主服務器就需要向從服務器執(zhí)行命令傳播操作 ，即把剛才造成不一致的寫命令，發(fā)送給從服務器去執(zhí)行。從服務器執(zhí)行完成之后，主從數(shù)據(jù)庫狀態(tài)就又恢復一致了。
這里插播一個疑問：
不知道有沒有的讀者覺得，當發(fā)生上述不一致的情況后，Redis 再執(zhí)行同步操作不就 ok 了嗎？
從效果上來說，的確是可以恢復同步，但其實沒有必要。原因是實現(xiàn)同步的 sync 命令是一個非常消耗資源的操作，看完下圖的說明，相信你肯定理解的。
既然同步是一個非常消耗資源的操作，那 Redis 有沒有什么優(yōu)化方法呢？答案當然是有的。
2.3 優(yōu)化版同步操作
還記得上面說的內(nèi)容嗎 —— 2.8 版本開始，進行主從同步可能只需要執(zhí)行命令傳播即可。這個也是因為 sync 比較耗資源，從而采取的優(yōu)化。
那什么時候可以這么做呢？我們先看下前提條件：
主從同步實際分 2 種情況：
- 初次復制：從服務器第一次復制當前主服務器（PS：主服務器是有可能更換的）
- 斷線后重復制：處于命令傳播階段的主從服務器，因為網(wǎng)絡問題而中斷復制，從服務器通過自動重連，重新連接上主服務器并繼續(xù)復制。
在斷線后重復制的情況下，在 2.8 版本之前，會再次執(zhí)行同步（sync 命令）和命令傳播。
如果說，在斷線期間，主服務器（已有上萬鍵值對）只執(zhí)行了幾個寫命令，為了讓從服務器彌補這幾個命令，卻要重新執(zhí)行 sync 來生成新的 rdb 文件，這也是非常低效的。
為了解決這個問題，2.8 開始就使用 psync 命令來代替 sync 命令去執(zhí)行同步操作。
psync 具有完整重同步和部分重同步兩種模式：
- 完整重同步：用于初次復制情況，執(zhí)行過程同 sync，在這不贅述了。
- 部分重同步：用于斷線后重復制情況，如果滿足一定條件，主服務器只需要將斷線期間執(zhí)行的寫命令發(fā)送給從服務器即可。
因此很明顯，當主從同步出現(xiàn)斷線后重復制的情況，psync 的部分重同步模式可以解決 sync 的低效情況。
上面的介紹中，出現(xiàn)了「滿足一定條件」，那又是鬼什么條件呢？—— 其實就是一個偏移量的比較，具體可以繼續(xù)往下看。
2.4 部分重同步的實現(xiàn)
部分重同步功能由以下 3 部分組成：
- 主從服務器的復制偏移量
- 主服務器的復制積壓緩沖區(qū)
- 服務器的運行 id（run id）
2.4.1 復制偏移量
執(zhí)行復制的主從服務器都會分別維護各自的復制偏移量：
- 主服務器每次向從服務器傳播 n 個字節(jié)數(shù)據(jù)時，都會將自己的復制偏移量加 n。
- 從服務器接受主服務器傳來的數(shù)據(jù)時，也會將自己的復制偏移量加 n
舉個例子：
若當前主服務器的復制偏移量為 10000，此時向從服務器傳播 30 個字節(jié)數(shù)據(jù)，結(jié)束后復制偏移量為 10030。
這時，從服務器還沒接收這 30 個字節(jié)數(shù)據(jù)就斷線了，然后重新連接上之后，該從服務器的復制偏移量依舊為 10000，說明主從數(shù)據(jù)不一致，此時會向主服務器發(fā)送 psync 命令。
那么主服務器應該對從服務器執(zhí)行完整重同步還是部分重同步呢？如果執(zhí)行部分重同步的話，主服務器又如何知道同步哪些數(shù)據(jù)給從服務器呢？
以下答案都和復制積壓緩沖區(qū)有關
2.4.2 復制積壓緩沖區(qū)
首先，復制積壓緩沖區(qū)是一個固定長度，先進先出的隊列，默認 1MB。
當主服務器進行命令傳播時，不僅會將命令發(fā)送給從服務器，還會發(fā)送給這個緩沖區(qū)。
因此復制積壓緩沖區(qū)的構(gòu)造是這樣的：
當從服務器向主服務器發(fā)送 psync 命令時，還需要將自己的復制偏移量帶上，主服務器就可以通過這個復制偏移量和復制積壓緩沖區(qū)的偏移量進行對比。
若復制積壓緩沖區(qū)存在從服務器的復制偏移量 + 1 后的數(shù)據(jù)，則進行部分重同步，否則進行完整重同步。
2.4.3 run id
運行 id 是在進行初次復制時，主服務器將會將自己的運行 id 發(fā)送給從服務器，讓其保存起來。
當從服務器斷線重連后，從服務器會將這個運行 id 發(fā)送給剛連接上的主服務器。
若當前服務器的運行 id 與之相同，說明從服務器斷線前復制的服務器就是當前服務器，主服務器可以嘗試執(zhí)行部分同步；若不同則說明從服務器斷線前復制的服務器不是當前服務器，主服務器直接執(zhí)行完整重同步。
花了很多筆墨，終于把部分重同步的實現(xiàn)寫完了，最后補充一個輔助功能
2.5 心跳檢測
剛才提到，主從同步有同步和命令傳播 2 個步驟。
當完成了同步之后，主從服務器就會進入命令傳播階段，此時從服務器會以每秒 1 次的頻率，向主服務器發(fā)送命令：REPLCONF ACK replication_offset> 其中 replication_offset 是從服務器當前的復制偏移量
發(fā)送這個命令主要有三個作用：
- 檢測主從服務器的網(wǎng)絡狀態(tài)
- 輔助實現(xiàn) min-slaves 選項
- 檢測命令丟失（若丟失，主服務器會將丟失的寫命令重新發(fā)給從服務器）
3. 總結(jié)
終于寫完了最后內(nèi)容，幾個小時又過去了，我們來總結(jié)下本文內(nèi)容吧：
發(fā)送 SLAVEOF 命令可以進行主從同步，比如：SLAVEOF 127.0.0.6379
主從同步有同步和命令傳播 2 個步驟。
- 同步：將從服務器的數(shù)據(jù)庫狀態(tài)更新成主服務器當前的數(shù)據(jù)庫狀態(tài)（一個消耗資源的操作）
- 命令傳播：當主服務器數(shù)據(jù)庫狀態(tài)被修改后，導致主從服務器數(shù)據(jù)庫狀態(tài)不一致，此時需要讓主從數(shù)據(jù)同步到一致的過程
主從同步分初次復制和斷線后重復制兩種情況
- 從 2.8 版本開始，在出現(xiàn)斷線后重復制情況時，主服務器會根據(jù)復制偏移量、復制積壓緩沖區(qū)和 run id，來確定執(zhí)行完整重同步還是部分重同步
2.8 版本使用 psync 命令來代替 sync 命令去執(zhí)行同步操作。目的是為了解決同步（sync 命令）的低效操作
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內(nèi)容請查看下面相關鏈接
您可能感興趣的文章:- Linux下redis的持久化、主從同步與哨兵詳解
- Redis的主從同步解析
- Redis主從同步配置的方法步驟(圖文)
