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

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

復(fù)制

在Redis中，用戶可以通過執(zhí)行 SLAVEOF 命令或者設(shè)置 slaveof 選項，讓一個服務(wù)去復(fù)制（replicate）另一個服務(wù)器。「被復(fù)制」的服務(wù)器為「主服務(wù)器（master）」，另一「個對主服務(wù)器進行復(fù)制」的服務(wù)器則被稱為「從服務(wù)器（slave）」

舉個🌰：(Redis版本是4.0.8）

在6379端口啟動一個redis-server： 

$ redis-server --port 6379  
$ redis-cli -p 6379  
127.0.0.1:6379>  

在6380端口號啟動一個redis-server，接著通過slaveof命令進行復(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（子線程中運行）生成 RDB 文件，發(fā)送給從服務(wù)器
•  主服務(wù)器在 BGSAVE 過程中的寫操作，保存在緩沖區(qū)中，發(fā)送給從服務(wù)器

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

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

舊版指的是2.8之前

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          當(dāng)從服務(wù)器重新連上主服務(wù)器時，從服務(wù)器會通過PSYNC命令將自己的offset發(fā)送給主服務(wù)器，主服務(wù)器會根據(jù)這個復(fù)制偏移量來決定對從服務(wù)器執(zhí)行何種同步操作。

•  服務(wù)器的「運行ID（run ID）」

           每個服務(wù)器都有自己的運行 ID，在服務(wù)器啟動時自動生成，由 40 個堆積的十六進制字符組成。

    當(dāng)從服務(wù)器對主服務(wù)器進行初次復(fù)制時，主服務(wù)器會將自己的運行ID傳送給從服務(wù)器，而從服務(wù)器則會將這個運行ID保存起來。

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

PSYNC命令實現(xiàn)

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

心跳檢測

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

$ REPLCONF ACK <replication_offset> 

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

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

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

小結(jié)

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