一篇文章讓你明白R(shí)edis主從同步

今天想和大家分享有關(guān) redis 主從同步(也稱「復(fù)制」)的內(nèi)容。

創(chuàng)新互聯(lián)建站是少有的成都做網(wǎng)站、網(wǎng)站制作、營銷型企業(yè)網(wǎng)站、微信小程序定制開發(fā)、手機(jī)APP,開發(fā)、制作、設(shè)計(jì)、買友情鏈接、推廣優(yōu)化一站式服務(wù)網(wǎng)絡(luò)公司,自2013年創(chuàng)立以來,堅(jiān)持透明化,價(jià)格低,無套路經(jīng)營理念。讓網(wǎng)頁驚喜每一位訪客多年來深受用戶好評(píng)

我們知道,當(dāng)有多臺(tái) Redis 服務(wù)器時(shí),肯定就有一臺(tái)主服務(wù)器和多臺(tái)從服務(wù)器。一般來說,主服務(wù)器進(jìn)行寫操作,從服務(wù)器進(jìn)行讀操作。

那么這里有存在一個(gè)問題:從服務(wù)器如何和主服務(wù)器進(jìn)行數(shù)據(jù)同步的呢?

這個(gè)問題,就是通過今天的內(nèi)容:主從同步來解決的。

文章內(nèi)容依舊比較干,建議大家靜下心來專心看,文末會(huì)給大家做個(gè)簡(jiǎn)單總結(jié)歸納。

1. 如何進(jìn)行主從同步

假如,現(xiàn)在有 2 臺(tái) Redis 服務(wù)器,地址分別是 127.0.0.1:6379 和 127.0.0.1:12345

我們?cè)?127.0.0.1:12345 的客戶端輸入命令:

127.0.0.1:12345> SLAVEOF 127.0.0.6379

如此 127.0.0.1:12345 服務(wù)器就會(huì)去復(fù)制 127.0.0.1:6379 的數(shù)據(jù)。即前者是從服務(wù)器,后者為主服務(wù)器。

除了以上方式進(jìn)行復(fù)制之外,還可以通過配置文件中的 slaveof 選項(xiàng)進(jìn)行設(shè)置。

可能,求知欲爆棚的你會(huì)想知道,Redis 是怎么進(jìn)行主從同步的?

ok,下面我們繼續(xù)了解一下。

2. 主從同步的實(shí)現(xiàn)過程

主從同步分為 2 個(gè)步驟:同步和命令傳播

  • 同步:將從服務(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í)需要讓主從數(shù)據(jù)同步到一致的過程。

上面就是主從同步 2 個(gè)步驟的作用,下面我打算稍微細(xì)說這兩個(gè)步驟的實(shí)現(xiàn)過程。

這里需要提前說明一下:在 Redis 2.8 版本之前,進(jìn)行主從復(fù)制時(shí)一定會(huì)順序執(zhí)行上述兩個(gè)步驟,而從 2.8 開始則可能只需要執(zhí)行命令傳播即可。在下文也會(huì)解釋為什么會(huì)這樣?

2.1 同步

從服務(wù)器對(duì)主服務(wù)的同步操作,需要通過 sync 命令來實(shí)現(xiàn),以下是 sync 命令的執(zhí)行步驟:

  1. 從服務(wù)器向主服務(wù)器發(fā)送 sync 命令
  2. 收到 sync 命令后,主服務(wù)器執(zhí)行 bgsave 命令,用來生成 rdb 文件,并在一個(gè)緩沖區(qū)中記錄從現(xiàn)在開始執(zhí)行的寫命令。
  3. bgsave 執(zhí)行完成后,將生成的 rdb 文件發(fā)送給從服務(wù)器,用來給從服務(wù)器更新數(shù)據(jù)
  4. 主服務(wù)器再將緩沖區(qū)記錄的寫命令發(fā)送給從服務(wù)器,從服務(wù)器執(zhí)行完這些寫命令后,此時(shí)的數(shù)據(jù)庫狀態(tài)便和主服務(wù)器一致了。

用圖表示就是這樣的:

一篇文章讓你明白R(shí)edis主從同步

2.2 命令傳播

經(jīng)過同步操作,此時(shí)主從的數(shù)據(jù)庫狀態(tài)其實(shí)已經(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ù)一致了。

這里插播一個(gè)疑問:

不知道有沒有的讀者覺得,當(dāng)發(fā)生上述不一致的情況后,Redis 再執(zhí)行同步操作不就 ok 了嗎?

從效果上來說,的確是可以恢復(fù)同步,但其實(shí)沒有必要。原因是實(shí)現(xiàn)同步的 sync 命令是一個(gè)非常消耗資源的操作,看完下圖的說明,相信你肯定理解的。

一篇文章讓你明白R(shí)edis主從同步

既然同步是一個(gè)非常消耗資源的操作,那 Redis 有沒有什么優(yōu)化方法呢?答案當(dāng)然是有的。

2.3 優(yōu)化版同步操作

還記得上面說的內(nèi)容嗎 —— 2.8 版本開始,進(jìn)行主從同步可能只需要執(zhí)行命令傳播即可。這個(gè)也是因?yàn)?sync 比較耗資源,從而采取的優(yōu)化。

那什么時(shí)候可以這么做呢?我們先看下前提條件:

主從同步實(shí)際分 2 種情況:

  • 初次復(fù)制:從服務(wù)器第一次復(fù)制當(dāng)前主服務(wù)器(PS:主服務(wù)器是有可能更換的)
  • 斷線后重復(fù)制:處于命令傳播階段的主從服務(wù)器,因?yàn)榫W(wǎng)絡(luò)問題而中斷復(fù)制,從服務(wù)器通過自動(dòng)重連,重新連接上主服務(wù)器并繼續(xù)復(fù)制。

在斷線后重復(fù)制的情況下,在 2.8 版本之前,會(huì)再次執(zhí)行同步(sync 命令)和命令傳播。

如果說,在斷線期間,主服務(wù)器(已有上萬鍵值對(duì))只執(zhí)行了幾個(gè)寫命令,為了讓從服務(wù)器彌補(bǔ)這幾個(gè)命令,卻要重新執(zhí)行 sync 來生成新的 rdb 文件,這也是非常低效的。

為了解決這個(gè)問題,2.8 開始就使用 psync 命令來代替 sync 命令去執(zhí)行同步操作。

psync 具有完整重同步和部分重同步兩種模式:

  • 完整重同步:用于初次復(fù)制情況,執(zhí)行過程同 sync,在這不贅述了。
  • 部分重同步:用于斷線后重復(fù)制情況,如果滿足一定條件,主服務(wù)器只需要將斷線期間執(zhí)行的寫命令發(fā)送給從服務(wù)器即可。

因此很明顯,當(dāng)主從同步出現(xiàn)斷線后重復(fù)制的情況,psync 的部分重同步模式可以解決 sync 的低效情況。

上面的介紹中,出現(xiàn)了「滿足一定條件」,那又是鬼什么條件呢?—— 其實(shí)就是一個(gè)偏移量的比較,具體可以繼續(xù)往下看。

2.4 部分重同步的實(shí)現(xiàn)

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

  • 主從服務(wù)器的復(fù)制偏移量
  • 主服務(wù)器的復(fù)制積壓緩沖區(qū)
  • 服務(wù)器的運(yùn)行 id(run id)

2.4.1 復(fù)制偏移量

執(zhí)行復(fù)制的主從服務(wù)器都會(huì)分別維護(hù)各自的復(fù)制偏移量:

  • 主服務(wù)器每次向從服務(wù)器傳播 n 個(gè)字節(jié)數(shù)據(jù)時(shí),都會(huì)將自己的復(fù)制偏移量加 n。
  • 從服務(wù)器接受主服務(wù)器傳來的數(shù)據(jù)時(shí),也會(huì)將自己的復(fù)制偏移量加 n

舉個(gè)例子:

若當(dāng)前主服務(wù)器的復(fù)制偏移量為 10000,此時(shí)向從服務(wù)器傳播 30 個(gè)字節(jié)數(shù)據(jù),結(jié)束后復(fù)制偏移量為 10030。

這時(shí),從服務(wù)器還沒接收這 30 個(gè)字節(jié)數(shù)據(jù)就斷線了,然后重新連接上之后,該從服務(wù)器的復(fù)制偏移量依舊為 10000,說明主從數(shù)據(jù)不一致,此時(shí)會(huì)向主服務(wù)器發(fā)送 psync 命令。

那么主服務(wù)器應(yīng)該對(duì)從服務(wù)器執(zhí)行完整重同步還是部分重同步呢?如果執(zhí)行部分重同步的話,主服務(wù)器又如何知道同步哪些數(shù)據(jù)給從服務(wù)器呢?

以下答案都和復(fù)制積壓緩沖區(qū)有關(guān)

2.4.2 復(fù)制積壓緩沖區(qū)

首先,復(fù)制積壓緩沖區(qū)是一個(gè)固定長度,先進(jìn)先出的隊(duì)列,默認(rèn) 1MB。

當(dāng)主服務(wù)器進(jìn)行命令傳播時(shí),不僅會(huì)將命令發(fā)送給從服務(wù)器,還會(huì)發(fā)送給這個(gè)緩沖區(qū)。

因此復(fù)制積壓緩沖區(qū)的構(gòu)造是這樣的:

一篇文章讓你明白R(shí)edis主從同步

當(dāng)從服務(wù)器向主服務(wù)器發(fā)送 psync 命令時(shí),還需要將自己的復(fù)制偏移量帶上,主服務(wù)器就可以通過這個(gè)復(fù)制偏移量和復(fù)制積壓緩沖區(qū)的偏移量進(jìn)行對(duì)比。

若復(fù)制積壓緩沖區(qū)存在從服務(wù)器的復(fù)制偏移量 + 1 后的數(shù)據(jù),則進(jìn)行部分重同步,否則進(jìn)行完整重同步。

2.4.3 run id

運(yùn)行 id 是在進(jìn)行初次復(fù)制時(shí),主服務(wù)器將會(huì)將自己的運(yùn)行 id 發(fā)送給從服務(wù)器,讓其保存起來。

當(dāng)從服務(wù)器斷線重連后,從服務(wù)器會(huì)將這個(gè)運(yùn)行 id 發(fā)送給剛連接上的主服務(wù)器。

若當(dāng)前服務(wù)器的運(yùn)行 id 與之相同,說明從服務(wù)器斷線前復(fù)制的服務(wù)器就是當(dāng)前服務(wù)器,主服務(wù)器可以嘗試執(zhí)行部分同步;若不同則說明從服務(wù)器斷線前復(fù)制的服務(wù)器不是當(dāng)前服務(wù)器,主服務(wù)器直接執(zhí)行完整重同步。

花了很多筆墨,終于把部分重同步的實(shí)現(xiàn)寫完了,最后補(bǔ)充一個(gè)輔助功能

2.5 心跳檢測(cè)

剛才提到,主從同步有同步和命令傳播 2 個(gè)步驟。

當(dāng)完成了同步之后,主從服務(wù)器就會(huì)進(jìn)入命令傳播階段,此時(shí)從服務(wù)器會(huì)以每秒 1 次的頻率,向主服務(wù)器發(fā)送命令:REPLCONF ACK <replication_offset> 其中 replication_offset 是從服務(wù)器當(dāng)前的復(fù)制偏移量

發(fā)送這個(gè)命令主要有三個(gè)作用:

  • 檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)狀態(tài)
  • 輔助實(shí)現(xiàn) min-slaves 選項(xiàng)
  • 檢測(cè)命令丟失(若丟失,主服務(wù)器會(huì)將丟失的寫命令重新發(fā)給從服務(wù)器)

3. 總結(jié)

終于寫完了最后內(nèi)容,幾個(gè)小時(shí)又過去了,我們來總結(jié)下本文內(nèi)容吧:

發(fā)送 SLAVEOF 命令可以進(jìn)行主從同步,比如:SLAVEOF 127.0.0.6379

主從同步有同步和命令傳播 2 個(gè)步驟。

  • 同步:將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新成主服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)(一個(gè)消耗資源的操作)
  • 命令傳播:當(dāng)主服務(wù)器數(shù)據(jù)庫狀態(tài)被修改后,導(dǎo)致主從服務(wù)器數(shù)據(jù)庫狀態(tài)不一致,此時(shí)需要讓主從數(shù)據(jù)同步到一致的過程

主從同步分初次復(fù)制和斷線后重復(fù)制兩種情況

  • 從 2.8 版本開始,在出現(xiàn)斷線后重復(fù)制情況時(shí),主服務(wù)器會(huì)根據(jù)復(fù)制偏移量、復(fù)制積壓緩沖區(qū)和 run id,來確定執(zhí)行完整重同步還是部分重同步

2.8 版本使用 psync 命令來代替 sync 命令去執(zhí)行同步操作。目的是為了解決同步(sync 命令)的低效操作

以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)創(chuàng)新互聯(lián)的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

當(dāng)前名稱:一篇文章讓你明白R(shí)edis主從同步
URL地址:http://bm7419.com/article22/pcsicc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站設(shè)計(jì)企業(yè)網(wǎng)站制作、定制網(wǎng)站服務(wù)器托管、網(wǎng)站維護(hù)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都定制網(wǎng)站建設(shè)