2021年了，Redis復(fù)制原理你應(yīng)該理解！
點(diǎn)擊上方 好好學(xué)java ，選擇 星標(biāo) 公眾號(hào)
重磅資訊，干貨，第一時(shí)間送達(dá) 今日推薦：14 個(gè) github 項(xiàng)目！
個(gè)人原創(chuàng)100W +訪(fǎng)問(wèn)量博客：點(diǎn)擊前往，查看更多
作者：JingQ
https://www.sevenyuan.cn/
Redis的單機(jī)模式不難，配置文件參數(shù)了解具體含義，設(shè)定業(yè)務(wù)上符合自己的就好了。
之前記錄了關(guān)于Redis的數(shù)據(jù)結(jié)構(gòu)和對(duì)象的知識(shí)（可以點(diǎn)Redis標(biāo)簽看看），下面開(kāi)始填坑。
復(fù)制
在Redis中，用戶(hù)可以通過(guò)執(zhí)行 SLAVEOF 命令或者設(shè)置 slaveof 選項(xiàng)，讓一個(gè)服務(wù)去復(fù)制（replicate）另一個(gè)服務(wù)器。「被復(fù)制」的服務(wù)器為「主服務(wù)器（master）」，另一「?jìng)€(gè)對(duì)主服務(wù)器進(jìn)行復(fù)制」的服務(wù)器則被稱(chēng)為「從服務(wù)器（slave）」
舉個(gè)??：(Redis版本是4.0.8）
在6379端口啟動(dòng)一個(gè)redis-server：
$ redis-server --port 6379
$ redis-cli -p 6379
127.0.0.1:6379>
在6380端口號(hào)啟動(dòng)一個(gè)redis-server，接著通過(guò)slaveof命令進(jìn)行復(fù)制
$ redis-server --port 6380
$ redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
在這里，6379 是主服務(wù)器，6380 是從服務(wù)器。
接著能在 6380 的 redis-server 界面中看到日志：
19092:S 23 Mar 01:00:26.944 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
19092:S 23 Mar 01:00:26.945 * SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=2 addr=127.0.0.1:60778 fd=8 name= age=50 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')
19092:S 23 Mar 01:00:27.234 * Connecting to MASTER 127.0.0.1:6379
19092:S 23 Mar 01:00:27.234 * MASTER <-> SLAVE sync started
19092:S 23 Mar 01:00:27.234 * Non blocking connect for SYNC fired the event.
19092:S 23 Mar 01:00:27.246 * Master replied to PING, replication can continue...
19092:S 23 Mar 01:00:27.246 * Trying a partial resynchronization (request 2e56cf1343f6b2e864c968bd59b4a16ed78b8f1d:1).
19092:S 23 Mar 01:00:27.266 * Full resync from master: bf36b20c3942e91ac4f262a2afdc90970b2d7c54:0
19092:S 23 Mar 01:00:27.266 * Discarding previously cached master state.
19092:S 23 Mar 01:00:27.441 * MASTER <-> SLAVE sync: receiving 187 bytes from master
19092:S 23 Mar 01:00:27.442 * MASTER <-> SLAVE sync: Flushing old data
19092:S 23 Mar 01:00:27.442 * MASTER <-> SLAVE sync: Loading DB in memory
19092:S 23 Mar 01:00:27.442 * MASTER <-> SLAVE sync: Finished with success
具體流程如下：
從服務(wù)器發(fā)送 「SYNC 命令」到主服務(wù)器
主服務(wù)器通過(guò) BGSAVE（子線(xiàn)程中運(yùn)行）生成 RDB 文件，發(fā)送給從服務(wù)器
主服務(wù)器在 BGSAVE 過(guò)程中的寫(xiě)操作，保存在緩沖區(qū)中，發(fā)送給從服務(wù)器
進(jìn)行復(fù)制中的主從服務(wù)器雙方的數(shù)據(jù)庫(kù)將保存相同的數(shù)據(jù)，概念上將這種現(xiàn)象稱(chēng)為**“數(shù)據(jù)庫(kù)狀態(tài)一致”，或者簡(jiǎn)稱(chēng)“一致”**。
舊版復(fù)制功能的缺陷
舊版指的是2.8之前
在Redis中，從服務(wù)器對(duì)主服務(wù)器的復(fù)制可以分成兩種情況：
「初次復(fù)制」：從服務(wù)器從前沒(méi)有復(fù)制過(guò)任何主服務(wù)器，或者從服務(wù)器當(dāng)前要復(fù)制的主服務(wù)器和上一次復(fù)制的主服務(wù)器不同。
「斷線(xiàn)后重新復(fù)制」：處于命令傳播階段的主從服務(wù)器因?yàn)榫W(wǎng)絡(luò)原因而中斷了復(fù)制，但從服務(wù)器通過(guò)自動(dòng)重連接重新連上了主服務(wù)器，繼續(xù)復(fù)制主服務(wù)器。
對(duì)于初次復(fù)制來(lái)說(shuō)來(lái)說(shuō)，舊版復(fù)制完全沒(méi)有問(wèn)題，但是斷線(xiàn)重連之后，如果當(dāng)時(shí)從服務(wù)器已經(jīng)復(fù)制了一些，重連之后，從服務(wù)器需要重新復(fù)制，造成一些浪費(fèi)。
「舊版使用的是SYNC命令進(jìn)行復(fù)制」，是一個(gè)非常浪費(fèi)資源的操作。
新版復(fù)制的優(yōu)勢(shì)
使用 PSYNC 命令替代 SYNC 命令來(lái)執(zhí)行復(fù)制時(shí)的同步操作。
具有**完整重同步（full resynchronization）「和」部分重同步（partial resynchronization）**兩種模式：
完整重同步：與初次復(fù)制相同，都是先讓主服務(wù)器發(fā)送 RDB 文件，以及向從服務(wù)器發(fā)送保存在緩沖區(qū)里面的命令來(lái)進(jìn)行同步。
部分重分步：當(dāng)從服務(wù)器斷線(xiàn)的時(shí)候，下次可以發(fā)起 PSYNC 命令，從中斷處開(kāi)始，執(zhí)行部分重同步，只需要將從服務(wù)器缺少的寫(xiě)命令發(fā)送給從服務(wù)器執(zhí)行就可以了，這時(shí)使用的資源比起執(zhí)行 SYNC 命令所需的資源要少的多。
新版復(fù)制實(shí)現(xiàn)
部分重同步功能由以下三個(gè)部分構(gòu)成：
主服務(wù)器的**復(fù)制偏移量（replication offset）**和從服務(wù)器的復(fù)制偏移量
主從服務(wù)器都各自持有一份復(fù)制偏移量。如果偏移量一致，表示處于一致?tīng)顟B(tài)；否則，兩者處于不一致?tīng)顟B(tài)。
主服務(wù)器的「復(fù)制積壓緩沖區(qū)（（replication backlog）」
復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護(hù)的一個(gè)「固定長(zhǎng)度（fixed-size）先進(jìn)先出（FIFO）隊(duì)列」，默認(rèn)是1MB。
主服務(wù)器的復(fù)制積壓緩沖區(qū)里面會(huì)保存著一部分最近傳播的寫(xiě)命令，并且復(fù)制積壓緩沖區(qū)會(huì)為隊(duì)列中的每個(gè)字節(jié)記錄相應(yīng)的復(fù)制偏移量。
當(dāng)從服務(wù)器重新連上主服務(wù)器時(shí)，從服務(wù)器會(huì)通過(guò)PSYNC命令將自己的offset發(fā)送給主服務(wù)器，主服務(wù)器會(huì)根據(jù)這個(gè)復(fù)制偏移量來(lái)決定對(duì)從服務(wù)器執(zhí)行何種同步操作。
服務(wù)器的「運(yùn)行ID（run ID）」
每個(gè)服務(wù)器都有自己的運(yùn)行 ID，在服務(wù)器啟動(dòng)時(shí)自動(dòng)生成，由 40 個(gè)堆積的十六進(jìn)制字符組成。
當(dāng)從服務(wù)器對(duì)主服務(wù)器進(jìn)行初次復(fù)制時(shí)，主服務(wù)器會(huì)將自己的運(yùn)行ID傳送給從服務(wù)器，而從服務(wù)器則會(huì)將這個(gè)運(yùn)行ID保存起來(lái)。
斷線(xiàn)重連后，如果從服務(wù)器保存的運(yùn)行 ID 與當(dāng)前鏈接的主服務(wù)器的運(yùn)行 ID 相同，主服務(wù)器會(huì)嘗試執(zhí)行「部分重同步操作」
相反的，如果不一致，主服務(wù)器將對(duì)從服務(wù)器執(zhí)行「完整重同步操作」。
PSYNC命令實(shí)現(xiàn)
具體調(diào)用看流程圖即可：
心跳檢測(cè)
在命令傳播階段，從服務(wù)器默認(rèn)會(huì)以每秒一次的頻率，向主服務(wù)器發(fā)送命令：
$ REPLCONF ACK <replication_offset>
其中replication_offset是從服務(wù)器當(dāng)前的復(fù)制偏移量。
發(fā)送REPLCONF ACK有三個(gè)作用：
檢測(cè)主從服務(wù)器的網(wǎng)絡(luò)連接情況
輔助實(shí)現(xiàn)min-slaves選項(xiàng)
檢測(cè)命令丟失
小結(jié)
部分重同步通過(guò)「復(fù)制偏移量、復(fù)制積壓緩沖區(qū)、服務(wù)器運(yùn)行 ID」 三個(gè)部分來(lái)實(shí)現(xiàn)。
在復(fù)制操作剛開(kāi)始的時(shí)候，從服務(wù)器會(huì)成為主服務(wù)器的客戶(hù)端，并通過(guò)向主服務(wù)器發(fā)送命令請(qǐng)求來(lái)執(zhí)行復(fù)制步驟，而在復(fù)制操作的后期，主從服務(wù)器互相成為對(duì)方的客戶(hù)端。
主服務(wù)器通過(guò)向從服務(wù)器傳播命令來(lái)更新從服務(wù)器的狀態(tài)，保持主從服務(wù)器一致，而從服務(wù)器則通過(guò)向主服務(wù)器發(fā)送命令來(lái)進(jìn)行心跳檢測(cè)，以及命令丟失檢測(cè)。
更多項(xiàng)目源碼