前言

關(guān)系數(shù)據(jù)庫(kù)通常會(huì)使用一個(gè)主服務(wù)器向多個(gè)從服務(wù)器發(fā)送更新，并使用從服務(wù)器來(lái)處理所有的讀請(qǐng)求，Redis采用了同樣方法來(lái)實(shí)現(xiàn)自己的復(fù)制特性。

簡(jiǎn)單總結(jié)起來(lái)就是：在接收到主服務(wù)器發(fā)送的數(shù)據(jù)初始副本之后，客戶(hù)端每次主服務(wù)器進(jìn)行寫(xiě)命令時(shí)，從服務(wù)器都會(huì)實(shí)時(shí)地得到更新。部署好主從服務(wù)器之后，客戶(hù)端可以向任意的從服務(wù)器發(fā)送讀請(qǐng)求。

本文主要介紹Redis實(shí)現(xiàn)數(shù)據(jù)同步復(fù)制簡(jiǎn)單過(guò)程、新舊版本之間的對(duì)比、復(fù)制的實(shí)現(xiàn)、以及一些需要注意的細(xì)節(jié)，但不會(huì)涉及Redis源碼解釋。只對(duì)基本流程及功能進(jìn)行詳細(xì)描述。

一、舊版復(fù)制功能

Redis 2.8以前采用的復(fù)制都為舊版復(fù)制，主要使用SYNC命令同步復(fù)制，SYNC存在很大的缺陷嚴(yán)重消耗主服務(wù)器的資源以及大量的網(wǎng)絡(luò)連接資源。Redis 2.8之后采用PSYNC命令替代SYNC，解決完善這些缺陷，但在介紹新版復(fù)制功能之前，必須先介紹舊版復(fù)制過(guò)程，這樣才能更好地形成對(duì)比。

1、復(fù)制功能的兩種模式

同時(shí)復(fù)制過(guò)程分為同步sync與命令傳播（command propagate），兩個(gè)過(guò)程配合執(zhí)行才能實(shí)現(xiàn)Redis復(fù)制。

1）同步操作：

通過(guò)從服務(wù)器發(fā)送到SYNC命令給主服務(wù)器-------->主服務(wù)器生成RDB文件并發(fā)送給從服務(wù)器，同時(shí)發(fā)送保存所有寫(xiě)命令給從服務(wù)器------>從服務(wù)器清空之前數(shù)據(jù)并執(zhí)行解釋RDB文件------->保持?jǐn)?shù)據(jù)一致（還需要命令傳播過(guò)程才能保持一致）

2）命令傳播操作：

主服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)被修改（主服務(wù)器執(zhí)行寫(xiě)命令，修改數(shù)據(jù)庫(kù)），導(dǎo)致主從服務(wù)器數(shù)據(jù)庫(kù)不一致時(shí)，通過(guò)發(fā)送讓主從服務(wù)器不一致的命令（主服務(wù)器接收到的新寫(xiě)命令）給從服務(wù)器并執(zhí)行，讓主從服務(wù)器的數(shù)據(jù)庫(kù)重新回到一致?tīng)顟B(tài)。

比如初次同步完成后，主從服務(wù)器數(shù)據(jù)庫(kù)中都已經(jīng)存在k1-k5的鍵，處于數(shù)據(jù)一致的狀態(tài)

之后，主服務(wù)器客戶(hù)端發(fā)送DEL刪除命令，刪除k3鍵，導(dǎo)致主從服務(wù)器數(shù)據(jù)不一致

2、配置選項(xiàng)前提

• 主從復(fù)制的前提不用多說(shuō)，就是先正確配置redis主從服務(wù)器，主要通過(guò)slaveof ip port選項(xiàng)配置或者SLAVEOF 命令。
• 保證主服務(wù)器的RDB+AOF配置正確，特別是RDB中dbfilename選項(xiàng)與AOF中的dir選項(xiàng)，兩個(gè)文件路徑對(duì)于Redis是可寫(xiě)的

3、主從復(fù)制過(guò)程

文字簡(jiǎn)單總結(jié)描述：

• slave會(huì)建立和master的連接，然后發(fā)送sync命令；
• master都會(huì)啟動(dòng)一個(gè)后臺(tái)進(jìn)程執(zhí)行BGSAVE命令，將數(shù)據(jù)快快照保存到文件中，同時(shí)master主進(jìn)程會(huì)開(kāi)始收集新的寫(xiě)命令并緩存起來(lái)；、
• 后臺(tái)進(jìn)程完成寫(xiě)文件后，master發(fā)送文件給slave，slave將文件保存到磁盤(pán)上，然后加載到內(nèi)存恢復(fù)數(shù)據(jù)庫(kù)快照到slave上。
• 緊接著master就會(huì)把緩存命令轉(zhuǎn)發(fā)給slave，后續(xù)的master收到的寫(xiě)命令也通過(guò)跟slave連接發(fā)送給slave；
• 如果master同時(shí)接收到多個(gè)slave發(fā)來(lái)的同步連接請(qǐng)求，只會(huì)啟動(dòng)一個(gè)進(jìn)程來(lái)寫(xiě)數(shù)據(jù)庫(kù)鏡像，然后發(fā)送給所有slave。

也可以參考以下表，其中步驟1-4可以認(rèn)為是sync同步操作，而步驟5即為命令傳播模式　　

注意事項(xiàng)

• 從服務(wù)器在同步時(shí)，會(huì)清空所有數(shù)據(jù)，服務(wù)器在與主服務(wù)器進(jìn)行初連接時(shí)，數(shù)據(jù)庫(kù)中的所有數(shù)據(jù)都將丟失，替換成主服務(wù)器發(fā)送的數(shù)據(jù)。
• Redis不支持主主復(fù)制
• 主從復(fù)制不會(huì)阻塞master（不會(huì)阻塞master處理客戶(hù)端請(qǐng)求），相反slave在初次同步數(shù)據(jù)時(shí)會(huì)阻塞不能處理客戶(hù)端請(qǐng)求。
• 當(dāng)多個(gè)從服務(wù)器嘗試連接同一個(gè)主服務(wù)器的時(shí)候，就會(huì)出現(xiàn)以下兩種情況：一是：步驟3還未執(zhí)行，所有從服務(wù)器都會(huì)接收到相同的快照文件和相同緩沖區(qū)寫(xiě)命令。二是：步驟3正在執(zhí)行或者已經(jīng)執(zhí)行完畢，當(dāng)主服務(wù)器與較早的從服務(wù)器完成以上全部步驟之后，主服務(wù)器會(huì)新連接的從服務(wù)器重新依次執(zhí)行1-5步驟。
• 在大部分情況下，Redis會(huì)盡可能去減少?gòu)?fù)制所需要的工作，但是從服務(wù)器連接的時(shí)機(jī)不湊巧的話(huà)，只好多做一些外額外工作。
• 多個(gè)從服務(wù)器連接主服務(wù)器時(shí)候，同步數(shù)據(jù)可能會(huì)占用很大一部分的帶寬，可能會(huì)導(dǎo)致其他請(qǐng)求難以到達(dá)主服務(wù)器。

4、SYNC命令的缺陷

主要是主從服務(wù)器斷線(xiàn)后重復(fù)制，即處于命令傳播階段的主從服務(wù)器由于網(wǎng)絡(luò)斷開(kāi)，從服務(wù)器一直嘗試連接主服務(wù)器連接成功后，繼續(xù)復(fù)制主服務(wù)器。如下過(guò)程在主從服務(wù)器斷開(kāi)后重新連接期間，主服務(wù)器繼續(xù)執(zhí)行三個(gè)SET命令，導(dǎo)致從服務(wù)器連接后發(fā)送L SYNC命令，重新進(jìn)行了“全量”復(fù)制過(guò)程，RDB文件中包含k1-k10089全部的鍵。

其中可以明顯看出重新連接主服務(wù)器之后，SYNC命令創(chuàng)建包含k1-k10089的RDB文件。而事實(shí)上只需要再同步斷線(xiàn)后的k10087-k10089即可。SYNC的“全同步”對(duì)于從服務(wù)來(lái)說(shuō)是不必要的。

SYNC命令非常消耗資源，原因有三點(diǎn)：

• 主服務(wù)器執(zhí)行BGSAVE命令生成RDB文件，這個(gè)生成過(guò)程會(huì)大量消耗主服務(wù)器資源（CPU、內(nèi)存和磁盤(pán)I/O資源）
• 主服務(wù)器需要將自己生成的RBD文件發(fā)送給從從服務(wù)器，這個(gè)發(fā)送操作會(huì)消耗主從服務(wù)器大量的網(wǎng)絡(luò)資源（帶寬與流量）
• 接收到RDB文件你的從服務(wù)器需要載入RDB文件，載入期間從服務(wù)器會(huì)因?yàn)樽枞鴮?dǎo)致沒(méi)辦法處理命令請(qǐng)求。

二、新版復(fù)制功能

為了解決舊版本中斷線(xiàn)情況下SYNC低效問(wèn)題，在Redis 2.8之后使用PSYNC命令代替SYNC命令執(zhí)行復(fù)制同步操作，自然PSYNC具備完整重同步和部分重同步模式

• 完整重同步：跟舊版復(fù)制基本是一致的，可以理解為“全量”復(fù)制。
• 部分重同步：在命令傳播階段，斷線(xiàn)重復(fù)制只需要發(fā)送主服務(wù)器在斷開(kāi)期間執(zhí)行的寫(xiě)命給從服務(wù)器即可，可以理解為“增量”復(fù)制。

斷開(kāi)連接后發(fā)送+CONTINUE回復(fù)，表示使用PSYNC部分重同步，只需要同步k10087-10089即可，不需要生成RDB文件

相關(guān)流程圖如下：

三、復(fù)制的實(shí)現(xiàn)

Redis不管是舊版還是新版，復(fù)制的實(shí)現(xiàn)都可以分為七個(gè)步驟，流程圖如下：

1、設(shè)置主服務(wù)的地址與端口

當(dāng)客戶(hù)端向從服務(wù)器發(fā)送一下命令時(shí)或者在配置文件中配置slaveof選項(xiàng)

127.0.0.1:12345> SLAVEOF 127.0.0.1 6379

從服務(wù)器將向發(fā)送SLAVEOF命令的客戶(hù)端返回OK，表示復(fù)制指令已經(jīng)被接收，而實(shí)際上復(fù)制工作是在OK返回之后進(jìn)行。

2、建立套接字連接

從服務(wù)器根據(jù)設(shè)置的套接字創(chuàng)建連向主服務(wù)器的套接字連接

主服務(wù)器接收從服務(wù)器的套接字連接之后，為該套接字創(chuàng)建響應(yīng)的客戶(hù)端狀態(tài)，并將此時(shí)的從服務(wù)器看做是主服務(wù)器的客戶(hù)端，也就是該從服務(wù)器同時(shí)具備服務(wù)器與客戶(hù)端兩個(gè)身份。

3、發(fā)送PING命令

從服務(wù)器成為主服務(wù)器的客戶(hù)端之后，做的第一件事就是向主服務(wù)器發(fā)送PING命令。PING命令主要有兩種作用：

• 雖然建立了套接字連接，但是還未使用過(guò)，通過(guò)發(fā)送PING命令檢查套接字的讀寫(xiě)狀態(tài)是否正常
• 通過(guò)發(fā)送PING命令檢查主服務(wù)器能否正常處理命令請(qǐng)求

從服務(wù)器在發(fā)送PING命令之后將遇到以下三種情況的其中一種：

• 主服務(wù)器向從服務(wù)器返回一個(gè)回復(fù)，但是從服務(wù)器卻不能在規(guī)定的會(huì)時(shí)間（timeout）內(nèi)讀取命令回復(fù)的內(nèi)容，則表示當(dāng)前主從服務(wù)器之間的網(wǎng)絡(luò)狀態(tài)連接不佳，不能基礎(chǔ)執(zhí)行復(fù)制工作的后續(xù)步驟，這時(shí)從服務(wù)器會(huì)斷開(kāi)套接字連接重新創(chuàng)建。
• 主服務(wù)器向從服務(wù)器返回一個(gè)錯(cuò)誤，那么表示主服務(wù)器暫時(shí)沒(méi)有辦法處理從服務(wù)器的命令請(qǐng)求，不能繼續(xù)執(zhí)行復(fù)制工作的后續(xù)步驟，這時(shí)從服務(wù)器會(huì)斷開(kāi)套接字連接重新創(chuàng)建。
• 如果從服務(wù)器讀取到“PONG”回復(fù)，那么表示主從服務(wù)器之間網(wǎng)絡(luò)連接正常，并且主服務(wù)器可以處理從服務(wù)器發(fā)送的命令請(qǐng)求。

4、身份驗(yàn)證

從服務(wù)器接收到主服務(wù)器返回的“PONG”回復(fù)，接下來(lái)就需要考慮身份驗(yàn)證的事。

如果從服務(wù)器設(shè)置了masterauth選項(xiàng)，那么進(jìn)行身份驗(yàn)證

如果從服務(wù)器沒(méi)有設(shè)置masterauth選項(xiàng)，那么不進(jìn)行身份驗(yàn)證

從服務(wù)器在身份驗(yàn)證的時(shí)候可能遇到三種情況

• 主服務(wù)沒(méi)有設(shè)置requirepass選項(xiàng)，并且從服務(wù)器也沒(méi)有設(shè)置masterquth選項(xiàng)，那么主服務(wù)器繼續(xù)執(zhí)行從服務(wù)器命令，完成復(fù)制工作
• 如果從服務(wù)器通過(guò)AUTH命令發(fā)送的密碼與主服務(wù)器中requirepass密碼相同，那么主服務(wù)器將繼續(xù)執(zhí)行從服務(wù)器發(fā)送的命令，復(fù)制工作繼續(xù)，與此相反，密碼不一致，則會(huì)返回invalid password錯(cuò)誤
• 如果從服務(wù)器沒(méi)有設(shè)置masterauth選項(xiàng)，而主服務(wù)器設(shè)置了requirepass選項(xiàng)，那么主服務(wù)器將返回一個(gè)NOAUTH錯(cuò)誤。反之沒(méi)有設(shè)設(shè)置masterauth選項(xiàng)，而設(shè)置了requirepass選項(xiàng)，那么會(huì)返回no password is set錯(cuò)誤。

5、發(fā)送端口信息

在身份驗(yàn)證步驟之后，從服務(wù)器將執(zhí)行命令REPLCONF listening-port <port>，向主服務(wù)器發(fā)送從服務(wù)器的監(jiān)聽(tīng)端口號(hào)。

6、同步

就是上述所指的同步操作，從服務(wù)器向主服務(wù)器發(fā)送PSYNC命令，執(zhí)行同步操作，值得注意的是只有從服務(wù)器是主服務(wù)器的客戶(hù)端，但是執(zhí)行同步操作之后，主服務(wù)器也會(huì)成為從服務(wù)器的客戶(hù)端。

7、命令傳播

主從服務(wù)器就會(huì)進(jìn)入命令傳播階段，主服務(wù)器只要將自己執(zhí)行的寫(xiě)命令發(fā)送給從服務(wù)器，而從服務(wù)器只要一直執(zhí)行并接收主服務(wù)器發(fā)來(lái)的寫(xiě)命令（上述已經(jīng)介紹過(guò)，這里不過(guò)多介紹）

更多關(guān)于Java的技術(shù)和資訊可以關(guān)注我的專(zhuān)欄：

Java架構(gòu)筑基?zhuanlan.zhihu.com

專(zhuān)欄免費(fèi)給大家分享Java架構(gòu)的學(xué)習(xí)資料和視頻

總結(jié)

以上是生活随笔為你收集整理的实现同步请求_Redis的复制是如何实现的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。