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