Redis的單機(jī)模式不難，配置文件參數(shù)了解具體含義，設(shè)定業(yè)務(wù)上符合自己的就好了。

之前記錄了關(guān)于Redis的數(shù)據(jù)結(jié)構(gòu)和對(duì)象的知識(shí)（可以點(diǎn)Redis標(biāo)簽看看），下面開始填坑。

復(fù)制

在Redis中，用戶可以通過執(zhí)行 SLAVEOF 命令或者設(shè)置 slaveof 選項(xiàng)，讓一個(gè)服務(wù)去復(fù)制（replicate）另一個(gè)服務(wù)器?！副粡?fù)制」的服務(wù)器為「主服務(wù)器（master）」，另一「個(gè)對(duì)主服務(wù)器進(jìn)行復(fù)制」的服務(wù)器則被稱為「從服務(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，接著通過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ù)器通過 BGSAVE（子線程中運(yùn)行）生成 RDB 文件，發(fā)送給從服務(wù)器
•  主服務(wù)器在 BGSAVE 過程中的寫操作，保存在緩沖區(qū)中，發(fā)送給從服務(wù)器

進(jìn)行復(fù)制中的主從服務(wù)器雙方的數(shù)據(jù)庫將保存相同的數(shù)據(jù)，概念上將這種現(xiàn)象稱為**“數(shù)據(jù)庫狀態(tài)一致”，或者簡稱“一致”**。

舊版復(fù)制功能的缺陷

舊版指的是2.8之前

在Redis中，從服務(wù)器對(duì)主服務(wù)器的復(fù)制可以分成兩種情況：

•  「初次復(fù)制」：從服務(wù)器從前沒有復(fù)制過任何主服務(wù)器，或者從服務(wù)器當(dāng)前要復(fù)制的主服務(wù)器和上一次復(fù)制的主服務(wù)器不同。
•  「斷線后重新復(fù)制」：處于命令傳播階段的主從服務(wù)器因?yàn)榫W(wǎng)絡(luò)原因而中斷了復(fù)制，但從服務(wù)器通過自動(dòng)重連接重新連上了主服務(wù)器，繼續(xù)復(fù)制主服務(wù)器。

對(duì)于初次復(fù)制來說來說，舊版復(fù)制完全沒有問題，但是斷線重連之后，如果當(dāng)時(shí)從服務(wù)器已經(jīng)復(fù)制了一些，重連之后，從服務(wù)器需要重新復(fù)制，造成一些浪費(fèi)。

「舊版使用的是SYNC命令進(jìn)行復(fù)制」，是一個(gè)非常浪費(fèi)資源的操作。

新版復(fù)制的優(yōu)勢

使用 PSYNC 命令替代 SYNC 命令來執(zhí)行復(fù)制時(shí)的同步操作。

具有**完整重同步（full resynchronization）「和」部分重同步（partial resynchronization）**兩種模式：

•  完整重同步：與初次復(fù)制相同，都是先讓主服務(wù)器發(fā)送 RDB 文件，以及向從服務(wù)器發(fā)送保存在緩沖區(qū)里面的命令來進(jìn)行同步。
•  部分重分步：當(dāng)從服務(wù)器斷線的時(shí)候，下次可以發(fā)起 PSYNC 命令，從中斷處開始，執(zhí)行部分重同步，只需要將從服務(wù)器缺少的寫命令發(fā)送給從服務(wù)器執(zhí)行就可以了，這時(shí)使用的資源比起執(zhí)行 SYNC 命令所需的資源要少的多。

新版復(fù)制實(shí)現(xiàn)

部分重同步功能由以下三個(gè)部分構(gòu)成：

•  主服務(wù)器的**復(fù)制偏移量（replication offset）**和從服務(wù)器的復(fù)制偏移量

          主從服務(wù)器都各自持有一份復(fù)制偏移量。如果偏移量一致，表示處于一致狀態(tài)；否則，兩者處于不一致狀態(tài)。

•  主服務(wù)器的「復(fù)制積壓緩沖區(qū)（（replication backlog）」

          復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護(hù)的一個(gè)「固定長度（fixed-size）先進(jìn)先出（FIFO）隊(duì)列」，默認(rèn)是1MB。

          主服務(wù)器的復(fù)制積壓緩沖區(qū)里面會(huì)保存著一部分最近傳播的寫命令，并且復(fù)制積壓緩沖區(qū)會(huì)為隊(duì)列中的每個(gè)字節(jié)記錄相應(yīng)的復(fù)制偏移量。

          當(dāng)從服務(wù)器重新連上主服務(wù)器時(shí)，從服務(wù)器會(huì)通過PSYNC命令將自己的offset發(fā)送給主服務(wù)器，主服務(wù)器會(huì)根據(jù)這個(gè)復(fù)制偏移量來決定對(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保存起來。

•  斷線重連后，如果從服務(wù)器保存的運(yùn)行 ID 與當(dāng)前鏈接的主服務(wù)器的運(yùn)行 ID 相同，主服務(wù)器會(huì)嘗試執(zhí)行「部分重同步操作」
•  相反的，如果不一致，主服務(wù)器將對(duì)從服務(wù)器執(zhí)行「完整重同步操作」。

PSYNC命令實(shí)現(xiàn)

具體調(diào)用看流程圖即可：

心跳檢測

在命令傳播階段，從服務(wù)器默認(rèn)會(huì)以每秒一次的頻率，向主服務(wù)器發(fā)送命令： 

$ REPLCONF ACK <replication_offset> 

其中replication_offset是從服務(wù)器當(dāng)前的復(fù)制偏移量。

發(fā)送REPLCONF ACK有三個(gè)作用：

•  檢測主從服務(wù)器的網(wǎng)絡(luò)連接情況
•  輔助實(shí)現(xiàn)min-slaves選項(xiàng)
•  檢測命令丟失

小結(jié)

•  部分重同步通過「復(fù)制偏移量、復(fù)制積壓緩沖區(qū)、服務(wù)器運(yùn)行 ID」 三個(gè)部分來實(shí)現(xiàn)。
•  在復(fù)制操作剛開始的時(shí)候，從服務(wù)器會(huì)成為主服務(wù)器的客戶端，并通過向主服務(wù)器發(fā)送命令請(qǐng)求來執(zhí)行復(fù)制步驟，而在復(fù)制操作的后期，主從服務(wù)器互相成為對(duì)方的客戶端。
•  主服務(wù)器通過向從服務(wù)器傳播命令來更新從服務(wù)器的狀態(tài)，保持主從服務(wù)器一致，而從服務(wù)器則通過向主服務(wù)器發(fā)送命令來進(jìn)行心跳檢測，以及命令丟失檢測。