前言：
今天想和大家分享有關(guān) Redis 主從同步（也稱「復(fù)制」）的內(nèi)容帕棉。
我們知道针肥，當(dā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 個步驟：同步和命令傳播
- 同步：將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新成主服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)既棺。（數(shù)據(jù)庫狀態(tài)在這篇文章開頭有提到是什么意思讽挟，不清楚的小伙伴可以先看下：《持久化》）
- 命令傳播：當(dāng)主服務(wù)器數(shù)據(jù)庫狀態(tài)被修改后，導(dǎo)致主從服務(wù)器數(shù)據(jù)庫狀態(tài)不一致丸冕，此時需要讓主從數(shù)據(jù)同步到一致的過程耽梅。
上面就是主從同步 2 個步驟的作用，下面我打算稍微細說這兩個步驟的實現(xiàn)過程胖烛。
這里需要提前說明一下：在 Redis 2.8 版本之前眼姐，進行主從復(fù)制時一定會順序執(zhí)行上述兩個步驟，而從 2.8 開始則可能只需要執(zhí)行命令傳播即可洪己。在下文也會解釋為什么會這樣妥凳？
2.1 同步
從服務(wù)器對主服務(wù)的同步操作竟贯，需要通過 sync 命令來實現(xiàn)答捕，以下是 sync 命令的執(zhí)行步驟：
- 從服務(wù)器向主服務(wù)器發(fā)送 sync 命令
- 收到 sync 命令后，主服務(wù)器執(zhí)行 bgsave 命令屑那，用來生成 rdb 文件拱镐，并在一個緩沖區(qū)中記錄從現(xiàn)在開始執(zhí)行的寫命令艘款。
- bgsave 執(zhí)行完成后，將生成的 rdb 文件發(fā)送給從服務(wù)器沃琅，用來給從服務(wù)器更新數(shù)據(jù)
- 主服務(wù)器再將緩沖區(qū)記錄的寫命令發(fā)送給從服務(wù)器哗咆，從服務(wù)器執(zhí)行完這些寫命令后，此時的數(shù)據(jù)庫狀態(tài)便和主服務(wù)器一致了益眉。
用圖表示就是這樣的：
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ù)一致了响迂。
這里插播一個疑問：
不知道有沒有的讀者覺得，當(dāng)發(fā)生上述不一致的情況后细疚，Redis 再執(zhí)行同步操作不就 ok 了嗎栓拜？
從效果上來說，的確是可以恢復(fù)同步惠昔，但其實沒有必要幕与。原因是實現(xiàn)同步的 sync 命令是一個非常消耗資源的操作，看完下圖的說明镇防，相信你肯定理解的啦鸣。
在此我向大家推薦一個程序員交流群。交流學(xué)習(xí)群號：833145934 里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring来氧，MyBatis诫给，Netty源碼分析，高并發(fā)啦扬、高性能中狂、分布式、微服務(wù)架構(gòu)的原理扑毡，JVM性能優(yōu)化胃榕、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系。還能領(lǐng)取免費的學(xué)習(xí)資源與最新的BAT面試題瞄摊，目前受益良多
既然同步是一個非常消耗資源的操作勋又，那 Redis 有沒有什么優(yōu)化方法呢苦掘？答案當(dāng)然是有的。
2.3 優(yōu)化版同步操作
還記得上面說的內(nèi)容嗎 —— 2.8 版本開始楔壤，進行主從同步可能只需要執(zhí)行命令傳播即可鹤啡。這個也是因為 sync 比較耗資源，從而采取的優(yōu)化蹲嚣。
那什么時候可以這么做呢递瑰？我們先看下前提條件：
主從同步實際分 2 種情況：
- 初次復(fù)制：從服務(wù)器第一次復(fù)制當(dāng)前主服務(wù)器（PS：主服務(wù)器是有可能更換的）
- 斷線后重復(fù)制：處于命令傳播階段的主從服務(wù)器，因為網(wǎng)絡(luò)問題而中斷復(fù)制隙畜，從服務(wù)器通過自動重連泣矛，重新連接上主服務(wù)器并繼續(xù)復(fù)制。
在斷線后重復(fù)制的情況下禾蚕，在 2.8 版本之前您朽，會再次執(zhí)行同步（sync 命令）和命令傳播。
如果說换淆，在斷線期間哗总，主服務(wù)器（已有上萬鍵值對）只執(zhí)行了幾個寫命令，為了讓從服務(wù)器彌補這幾個命令倍试，卻要重新執(zhí)行 sync 來生成新的 rdb 文件讯屈，這也是非常低效的。
為了解決這個問題县习，2.8 開始就使用 psync 命令來代替 sync 命令去執(zhí)行同步操作涮母。
psync 具有完整重同步和部分重同步兩種模式：
- 完整重同步：用于初次復(fù)制情況，執(zhí)行過程同 sync躁愿，在這不贅述了叛本。
- 部分重同步：用于斷線后重復(fù)制情況，如果滿足一定條件彤钟，主服務(wù)器只需要將斷線期間執(zhí)行的寫命令發(fā)送給從服務(wù)器即可来候。
因此很明顯，當(dāng)主從同步出現(xiàn)斷線后重復(fù)制的情況逸雹，psync 的部分重同步模式可以解決 sync 的低效情況营搅。
上面的介紹中，出現(xiàn)了「滿足一定條件」梆砸，那又是鬼什么條件呢转质？—— 其實就是一個偏移量的比較，具體可以繼續(xù)往下看帖世。
2.4 部分重同步的實現(xiàn)
部分重同步功能由以下 3 部分組成：
- 主從服務(wù)器的復(fù)制偏移量
- 主服務(wù)器的復(fù)制積壓緩沖區(qū)
- 服務(wù)器的運行 id（run id）
2.4.1 復(fù)制偏移量
執(zhí)行復(fù)制的主從服務(wù)器都會分別維護各自的復(fù)制偏移量：
- 主服務(wù)器每次向從服務(wù)器傳播 n 個字節(jié)數(shù)據(jù)時休蟹，都會將自己的復(fù)制偏移量加 n。
- 從服務(wù)器接受主服務(wù)器傳來的數(shù)據(jù)時，也會將自己的復(fù)制偏移量加 n
舉個例子：
若當(dāng)前主服務(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堪遂。
當(dāng)主服務(wù)器進行命令傳播時，不僅會將命令發(fā)送給從服務(wù)器萌庆，還會發(fā)送給這個緩沖區(qū)溶褪。
因此復(fù)制積壓緩沖區(qū)的構(gòu)造是這樣的：
當(dāng)從服務(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ù)器占遥，讓其保存起來贰剥。
當(dāng)從服務(wù)器斷線重連后，從服務(wù)器會將這個運行 id 發(fā)送給剛連接上的主服務(wù)器筷频。
若當(dāng)前服務(wù)器的運行 id 與之相同蚌成，說明從服務(wù)器斷線前復(fù)制的服務(wù)器就是當(dāng)前服務(wù)器，主服務(wù)器可以嘗試執(zhí)行部分同步凛捏；若不同則說明從服務(wù)器斷線前復(fù)制的服務(wù)器不是當(dāng)前服務(wù)器担忧，主服務(wù)器直接執(zhí)行完整重同步。
花了很多筆墨坯癣，終于把部分重同步的實現(xiàn)寫完了瓶盛，最后補充一個輔助功能
2.5 心跳檢測
剛才提到，主從同步有同步和命令傳播 2 個步驟。
當(dāng)完成了同步之后惩猫，主從服務(wù)器就會進入命令傳播階段芝硬，此時從服務(wù)器會以每秒 1 次的頻率，向主服務(wù)器發(fā)送命令：REPLCONF ACK <replication_offset> 其中 replication_offset 是從服務(wù)器當(dāng)前的復(fù)制偏移量
發(fā)送這個命令主要有三個作用：
- 檢測主從服務(wù)器的網(wǎng)絡(luò)狀態(tài)
- 輔助實現(xiàn) min-slaves 選項
- 檢測命令丟失（若丟失轧房，主服務(wù)器會將丟失的寫命令重新發(fā)給從服務(wù)器）
3. 總結(jié)
發(fā)送 SLAVEOF 命令可以進行主從同步拌阴，比如：SLAVEOF 127.0.0.6379
主從同步有同步和命令傳播 2 個步驟。
- 同步：將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新成主服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)（一個消耗資源的操作）
- 命令傳播：當(dāng)主服務(wù)器數(shù)據(jù)庫狀態(tài)被修改后奶镶，導(dǎo)致主從服務(wù)器數(shù)據(jù)庫狀態(tài)不一致迟赃，此時需要讓主從數(shù)據(jù)同步到一致的過程
主從同步分初次復(fù)制和斷線后重復(fù)制兩種情況
- 從 2.8 版本開始，在出現(xiàn)斷線后重復(fù)制情況時厂镇，主服務(wù)器會根據(jù)復(fù)制偏移量纤壁、復(fù)制積壓緩沖區(qū)和 run id，來確定執(zhí)行完整重同步還是部分重同步
2.8 版本使用 psync 命令來代替 sync 命令去執(zhí)行同步操作捺信。目的是為了解決同步（sync 命令）的低效操作酌媒。
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值迄靠。
往期精彩內(nèi)容
《 面試總結(jié)：2019年最全面試題資料學(xué)習(xí)大全—（含答案） 》
