---

概念

Redis的最佳應(yīng)用，還是要在分布式系統(tǒng)中。對于非分布式系統(tǒng)，也就是只有一個主機(jī)提供服務(wù)，此時一旦該主機(jī)崩潰，那么整個服務(wù)就崩潰了，這稱為單點(diǎn)問題。

因此引入分布式系統(tǒng)，多個主機(jī)共同完成一個服務(wù)，既能提高服務(wù)并發(fā)的能力，又能避免單點(diǎn)問題，就算一個主機(jī)崩潰了，還有其他主機(jī)可以處理服務(wù)。

而分布式系統(tǒng)，常見的模式為以下三種：

1. 主從模式
2. 主從 + 哨兵模式
3. 集群模式

主從模式，顧名思義就是有主服務(wù)器（主節(jié)點(diǎn)）和從屬服務(wù)器從節(jié)點(diǎn)，此時從節(jié)點(diǎn)的所有數(shù)據(jù)都要去和主節(jié)點(diǎn)同步。那么從節(jié)點(diǎn)就要去復(fù)制主節(jié)點(diǎn)的數(shù)據(jù)，在Redis中，從節(jié)點(diǎn)復(fù)制了主節(jié)點(diǎn)的數(shù)據(jù)后，不允許修改，確保了數(shù)據(jù)完全來自于主節(jié)點(diǎn)。

這種模式下，寫入操作都會分配給主節(jié)點(diǎn)，而所有查詢操作都分配給從節(jié)點(diǎn)，這樣就能保證主節(jié)點(diǎn)的數(shù)據(jù)都是最新的，從節(jié)點(diǎn)通過數(shù)據(jù)同步，完成數(shù)據(jù)更新。

本博客講解Redis的主從模式。

---

配置主從模式

由于大部分人手上都只有一臺主機(jī)或者云服務(wù)器，此時想要打造一個分布式系統(tǒng)就需要用一些其他技巧，而不是真的在多個主機(jī)上部署分布式。

其實(shí)在一臺主機(jī)上，是可以允許多個redis-server進(jìn)程的，只要保證每個進(jìn)程的端口號不同，那么就可以有多個redis-server存在。

首先找一個合適的位置，創(chuàng)建一個目錄，用于存放從節(jié)點(diǎn)的配置文件：

拷貝redis,conf配置文件到當(dāng)前目錄，由于我打算創(chuàng)建兩個叢節(jié)點(diǎn)，所以拷貝了兩份。

找到port選項(xiàng)：

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379

默認(rèn)的端口號是6379，此端口號修改為其它端口，不要與主節(jié)點(diǎn)沖突。

找到daemon選項(xiàng)

# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
# When Redis is supervised by upstart or systemd, this parameter has no impact.
daemonize yes

保證該選項(xiàng)是yes，這樣Redis才能在后臺運(yùn)行。

修改這兩個配置文件后，通過以下指令啟動：

redis-server 配置文件地址

啟動后通過ps查看，可以看到同時有三個Redis在運(yùn)行：

我綁定的三個端口分別是：6379、6380、6381。

想要啟動不同的客戶端，只需要通過-p選項(xiàng)指定不同的端口：

但是此時三個節(jié)點(diǎn)是單獨(dú)的三個服務(wù)，還沒有構(gòu)成主從結(jié)構(gòu)。

配置主從需要通過slaveof，有以下三種方式：

1. 在配置?件中加?slaveof {masterHost} {masterPort}，當(dāng)Redis啟動時生效
2. 在 redis-server 啟動命令時加? --slaveof {masterHost} {masterPort}
3. 直接使?redis命令：slaveof {masterHost} {masterPort}

此處通過修改配置文件完成主從配置，因?yàn)槠涫浅志玫?#xff0c;后兩種方式在每車次啟動時都要輸入額外的命令。

在兩個slave.conf的最末尾加上以下內(nèi)容：

# 配置主從復(fù)制
slaveof 127.0.0.1 6379

再重啟兩個服務(wù)，此時兩個節(jié)點(diǎn)就變成了主節(jié)點(diǎn)的從節(jié)點(diǎn)了。

要先殺掉兩個進(jìn)行，kill -9 PID：

隨后再通過之前的命令啟動：

redis-server ./slave1.conf 
redis-server ./slave2.conf 

通過netstat查看網(wǎng)絡(luò)情況：

可以發(fā)現(xiàn)，除了三個redis-server，還有很多其它的redis網(wǎng)絡(luò)連接，這是因?yàn)橹鲝闹g，要進(jìn)行數(shù)據(jù)傳輸，所以要創(chuàng)建額外的網(wǎng)絡(luò)連接。

測試一下：

左側(cè)端口為6379主節(jié)點(diǎn)，右側(cè)為6380從節(jié)點(diǎn)，主節(jié)點(diǎn)設(shè)置key1 111，從節(jié)點(diǎn)可以get得到，但是當(dāng)從節(jié)點(diǎn)試圖寫入數(shù)據(jù)，發(fā)生報錯，表示不允許修改數(shù)據(jù)。

---

info replication

通過指令info replication，可以查看主從相關(guān)的信息。

• 主節(jié)點(diǎn)6379：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=1602971,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=1602971,lag=0
master_failover_state:no-failover
master_replid:23006f1139dc753a96d489311987709770f6c36d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1602971
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:551881
repl_backlog_histlen:1051091

• role：表示當(dāng)前節(jié)點(diǎn)為主節(jié)點(diǎn)

• connected_slaves：當(dāng)前有兩個從節(jié)點(diǎn)

• slave0：第一個從節(jié)點(diǎn)的相關(guān)信息，

  • ip：地址
  • port：端口
  • state：狀態(tài)
  • offset：同步情況，多個從節(jié)點(diǎn)的該值可能不同，因?yàn)橥绞且獣r間的
  • lag：當(dāng)前主從節(jié)點(diǎn)之間數(shù)據(jù)傳輸?shù)难舆t

• master_replid：主節(jié)點(diǎn)的專屬id

• offset：主節(jié)點(diǎn)的數(shù)據(jù)進(jìn)度，與從節(jié)點(diǎn)的offset匹配，如果從節(jié)點(diǎn)的offset小于主節(jié)點(diǎn)，說明從節(jié)點(diǎn)沒有同步完畢，數(shù)據(jù)版本是落后的

• repl_backlog_xxx：積壓緩沖區(qū)，后續(xù)講解

• 從節(jié)點(diǎn)6380：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:1602985
slave_repl_offset:1602985
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:23006f1139dc753a96d489311987709770f6c36d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1602985
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:551895
repl_backlog_histlen:1051091

• master_xxx：主節(jié)點(diǎn)的一些信息
• slave_priority：一個優(yōu)先級，如果主節(jié)點(diǎn)崩潰了，會從新選主節(jié)點(diǎn)，與該優(yōu)先級有關(guān)
• master_replid：主節(jié)點(diǎn)的id

這些內(nèi)容也不需要記憶，可以去官網(wǎng)查詢，官方文檔有很詳細(xì)的解釋。

---

slave-read-only

默認(rèn)情況下，從節(jié)點(diǎn)只能讀取數(shù)據(jù)。其實(shí)從節(jié)點(diǎn)也可以通過配置文件修改的，只需要把slave-read-only=no，此時從節(jié)點(diǎn)就可以修改數(shù)據(jù)。但是要注意的是，從節(jié)點(diǎn)修改的數(shù)據(jù)，是不會同步給主節(jié)點(diǎn)的，這就會導(dǎo)致主從的數(shù)據(jù)不一致，所以不要修改這個配置文件。

---

tcp-nodelay

Redis主從之間，是通過TCP連接完成數(shù)據(jù)的同步的，在TCP內(nèi)部，有一個nagel算法，它是一種捎帶應(yīng)答機(jī)制的實(shí)現(xiàn)。如果啟用了該選項(xiàng)，那么TCP的延遲就會變高，但是消耗的帶寬會降低。

而主從之間有時候需要高頻同步數(shù)據(jù)，這就對TCP延遲有很高的要求，如果延遲太大，主從數(shù)據(jù)不一致，查詢時就很有可能得到過期的數(shù)據(jù)。那么此時就可以通過設(shè)置tcp-nodelay，關(guān)閉這個nagel算法，這樣雖然帶寬增加了，但是延遲就會降低。

這兩種方式傳輸沒有好壞之分，而是根據(jù)場景需求，如果網(wǎng)絡(luò)環(huán)境比較復(fù)雜，消耗帶寬太高，就很容易丟包，這就得不償失了。比如在同一個機(jī)房內(nèi)部署的服務(wù)器，那么此時網(wǎng)絡(luò)就很簡單，建議關(guān)閉這個nagel算法。但是如果是跨越很遠(yuǎn)的數(shù)據(jù)傳輸，比如說在好幾個地域布置了機(jī)房，構(gòu)建了一個跨越全國甚至全球的分布式系統(tǒng)，此時還是開啟這個nagel比較好。

---

命令

slaveof

• slaveof no one用于斷開主從關(guān)系，從節(jié)點(diǎn)執(zhí)行該命令后，就不再有主節(jié)點(diǎn)了，而是自成主節(jié)點(diǎn)。

示例：

從節(jié)點(diǎn)6380執(zhí)行slaveof no one后，再次info replication，role:master說明此時自己已經(jīng)是主節(jié)點(diǎn)了，不再從屬其他節(jié)點(diǎn)。要注意的是，從節(jié)點(diǎn)變成主節(jié)點(diǎn)后，原先的數(shù)據(jù)不會丟失，可以繼續(xù)操作原先的數(shù)據(jù)。

• slaveof用于設(shè)置當(dāng)前節(jié)點(diǎn)為其它節(jié)點(diǎn)的主節(jié)點(diǎn)。

語法：

slaveof ip port 

示例：

此處通過slaveof重新將6379設(shè)置為了6380的主節(jié)點(diǎn)。

不論是salveof，還是slaveof no one，都是臨時修改主從關(guān)系，一旦服務(wù)重啟，仍然依照配置文件設(shè)置主從關(guān)系。

---

主從結(jié)構(gòu)

在Redis中，有很多種主從的組織方式，它們構(gòu)成了不同的拓?fù)浣Y(jié)構(gòu)。

一主一從

最簡單的主從結(jié)構(gòu)，自然是一主一從，如下：

這種結(jié)構(gòu)的功能，一般是為了防止單點(diǎn)問題，如果主節(jié)點(diǎn)崩潰，此時從節(jié)點(diǎn)立刻代替主節(jié)點(diǎn)完成服務(wù)。當(dāng)寫命令并發(fā)量較高時，從節(jié)點(diǎn)上開始AOF持久化方式，但是主節(jié)點(diǎn)只使用RDB方式。這樣從節(jié)點(diǎn)就代替主節(jié)點(diǎn)完成持久化，而主節(jié)點(diǎn)可以空出更多的資源來完成寫入操作。

但是這種方式要關(guān)閉主節(jié)點(diǎn)的自動重啟功能，因?yàn)橹鞴?jié)點(diǎn)使用RDB持久化，此時數(shù)據(jù)往往不是最新的。一旦主節(jié)點(diǎn)重啟，那么就會通過RDB恢復(fù)數(shù)據(jù)，導(dǎo)致主節(jié)點(diǎn)得到舊數(shù)據(jù)。而這個舊數(shù)據(jù)又會同步給從節(jié)點(diǎn)，此時從節(jié)點(diǎn)的AOF新數(shù)據(jù)就被舊數(shù)據(jù)覆蓋了，這就很坑了。

---

一主多從

實(shí)際上，數(shù)據(jù)庫的查詢操作頻率是遠(yuǎn)大于插入操作的，所以一主多從往往是更常見的選擇，讓多個從節(jié)點(diǎn)完成讀取數(shù)據(jù)的任務(wù)，來提高并發(fā)能力。

• 星形結(jié)構(gòu)

這種情況下，往往還需要一個負(fù)載均衡器，來分發(fā)讀取的流量到多個從節(jié)點(diǎn)上，讓多個從節(jié)點(diǎn)接收差不多的訪問量。

但是這就會導(dǎo)致主節(jié)點(diǎn)要同時與好幾個從節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步，那么主節(jié)點(diǎn)的網(wǎng)絡(luò)壓力會很大，因此又出現(xiàn)了以下的樹形結(jié)構(gòu)。

• 樹形結(jié)構(gòu)

這種結(jié)構(gòu)下，主節(jié)點(diǎn)只需要與少量的從節(jié)點(diǎn)進(jìn)行同步，而其它節(jié)點(diǎn)作為從節(jié)點(diǎn)的從節(jié)點(diǎn)，完成二次同步。這樣就可以有效減少主節(jié)點(diǎn)的網(wǎng)絡(luò)壓力，但是這種情況下，數(shù)據(jù)的同步時間會變長，因?yàn)橐?jīng)過多層的同步。

樹形結(jié)構(gòu)和星形結(jié)構(gòu)也是各有優(yōu)劣，如果希望降低同步的時延，不怕主節(jié)點(diǎn)承擔(dān)太多網(wǎng)絡(luò)壓力，就用星形結(jié)構(gòu)。如果希望主節(jié)點(diǎn)的網(wǎng)絡(luò)壓力得到緩解，可以犧牲一部分同步時延，那么使用樹形結(jié)構(gòu)。

---

主從復(fù)制流程

接下來看一下主從關(guān)系是如何建立的，流程如下：

1. 保存主節(jié)點(diǎn)信息：

保存主節(jié)點(diǎn)的ip、port等信息

2. 建立主從TCP連接

從節(jié)點(diǎn)內(nèi)部通過每秒運(yùn)行的定時任務(wù)維護(hù)復(fù)制相關(guān)邏輯，當(dāng)定時任務(wù)發(fā)現(xiàn)存在新的主節(jié)點(diǎn)后，會嘗試與主節(jié)點(diǎn)建立基于TCP 的網(wǎng)絡(luò)連接。如果從節(jié)點(diǎn)無法建立連接，定時任務(wù)會無限重試直到連接成功或者用戶停止主從復(fù)制。

3. 從節(jié)點(diǎn)發(fā)送ping命令：

連接建立成功之后，從節(jié)點(diǎn)通過 ping命令確認(rèn)主節(jié)點(diǎn)在應(yīng)用層上是工作良好的。

4. 權(quán)限驗(yàn)證：

如果主節(jié)點(diǎn)設(shè)置了requirepass 參數(shù)，則需要密碼驗(yàn)證，從節(jié)點(diǎn)通過配置 masterauth參數(shù)來設(shè)置密碼。如果驗(yàn)證失敗，則從節(jié)點(diǎn)的復(fù)制將會停止。

5. 同步數(shù)據(jù)集：

對于首次建立復(fù)制的場景，主節(jié)點(diǎn)會把當(dāng)前持有的所有數(shù)據(jù)全部發(fā)送給從節(jié)點(diǎn)，這步操作基本是耗時最長的，所以又劃分稱兩種情況：全量同步和部分同步

6. 命令持續(xù)復(fù)制：

當(dāng)從節(jié)點(diǎn)復(fù)制了主節(jié)點(diǎn)的所有數(shù)據(jù)之后，針對之后的修改命令，主節(jié)點(diǎn)會持續(xù)的把命令發(fā)送給從節(jié)點(diǎn)，從節(jié)點(diǎn)執(zhí)行修改命令，保證主從數(shù)據(jù)的一致性。

接下來詳細(xì)講解一下，到底Redis是如何完成第5，6步驟中數(shù)據(jù)的同步的。

---

數(shù)據(jù)同步命令

Redis中提供了一個命令psync，其可以完成主從之間的數(shù)據(jù)同步過程。

語法：

psync replcationid offset

這兩個參數(shù)，需要進(jìn)行簡單的講解。

• replication id

replid稱為復(fù)制ID，每次主節(jié)點(diǎn)重啟，或者從節(jié)點(diǎn)晉升為主節(jié)點(diǎn)，都會生成一個replid，當(dāng)從節(jié)點(diǎn)與主節(jié)點(diǎn)建立連接后，從節(jié)點(diǎn)就可以得到主節(jié)點(diǎn)的replid。

通過info replication，可以查詢到以下內(nèi)容：

master_replid:23006f1139dc753a96d489311987709770f6c36d
master_replid2:0000000000000000000000000000000000000000

第一個master_replid，就記錄著主節(jié)點(diǎn)的replid，那么master_replid2的作用是什么？

有的時候，主節(jié)點(diǎn)網(wǎng)絡(luò)不好，從節(jié)點(diǎn)會誤判主節(jié)點(diǎn)下線，此時從節(jié)點(diǎn)就會晉升為主節(jié)點(diǎn)，也會生成自己的replid。此處的master_replid2，會把之前的主節(jié)點(diǎn)的replid記錄下來。

等到主節(jié)點(diǎn)網(wǎng)絡(luò)恢復(fù)后，重新與從節(jié)點(diǎn)建立連接，此時從節(jié)點(diǎn)不知道主節(jié)點(diǎn)是重啟了，還是網(wǎng)絡(luò)恢復(fù)了。就會拿master_replid2與主節(jié)點(diǎn)的replid對比，如果相同，說明主節(jié)點(diǎn)沒有重啟，只是網(wǎng)絡(luò)出問題了，此時從節(jié)點(diǎn)會重新認(rèn)主。如果不同，那么就是主節(jié)點(diǎn)下線了。

• offset

offset稱為偏移量，其用于維護(hù)節(jié)點(diǎn)的數(shù)據(jù)進(jìn)度，每當(dāng)主節(jié)點(diǎn)寫入數(shù)據(jù)后，都會把命令的字節(jié)長度進(jìn)行累加記錄到offset中。也就是說，隨著數(shù)據(jù)的寫入，這個值會越來越大。

而從節(jié)點(diǎn)每次更新數(shù)據(jù)，也會增加自己的偏移量，表示自己同步的進(jìn)度。當(dāng)從節(jié)點(diǎn)的偏移量和主節(jié)點(diǎn)的偏移量完全相同，那么說明從節(jié)點(diǎn)已經(jīng)同步到主節(jié)點(diǎn)的所有數(shù)據(jù)了。

replid 和 offset 共同確定一個唯一的數(shù)據(jù)集

只要 replid 和 offset 相同，那么兩個節(jié)點(diǎn)上的所有數(shù)據(jù)完全相同。

psync replcationid offset

如果 offset 為-1，那么此時進(jìn)行全量復(fù)制，將所有的數(shù)據(jù)都復(fù)制一份到從節(jié)點(diǎn)。如果offset為具體的一個偏移量，那么從節(jié)點(diǎn)將從偏移量開始往后的所有數(shù)據(jù)都復(fù)制過來。

如果psync不傳入任何參數(shù)，那么replid offset默認(rèn)為? 和-1，表示從節(jié)點(diǎn)不知道主節(jié)點(diǎn)的replid和offset。

但是不論從饑餓點(diǎn)發(fā)送什么命令，如果主節(jié)點(diǎn)過于繁忙，那么此時不一定會執(zhí)行從節(jié)點(diǎn)預(yù)期的復(fù)制方式。比如從節(jié)點(diǎn)申請進(jìn)行全量復(fù)制，此時主節(jié)點(diǎn)無法承受這么多網(wǎng)絡(luò)壓力，那么可能就會變成部分復(fù)制。

當(dāng)輸入psync后，可能得到以下三種結(jié)果：

1. +FULLRSYNC replid offset：進(jìn)行全量復(fù)制
2. +CONTINUE：進(jìn)行部分復(fù)制
3. -ERR：說明主節(jié)點(diǎn)不支持psync，此時可以使用sync

此處sync是在前臺運(yùn)行的命令，一旦執(zhí)行sync，主節(jié)點(diǎn)的所有命令都會被阻塞。

---

全量同步

全量復(fù)制是 Redis 最早支持的復(fù)制方式，主從第一次建立復(fù)制時必須進(jìn)行一次全量復(fù)制。

全量復(fù)制流程圖如下：

1. 從節(jié)點(diǎn)發(fā)送 psync命令給主節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步，由于是第一次進(jìn)行復(fù)制，從節(jié)點(diǎn)沒有主節(jié)點(diǎn)的運(yùn)行 ID 和復(fù)制偏移量，所以發(fā)送 psync ? -1。
2. 主節(jié)點(diǎn)根據(jù)命令，解析出要進(jìn)行全量復(fù)制，回復(fù)+FULLRESYNC響應(yīng)。
3. 從節(jié)點(diǎn)接收主節(jié)點(diǎn)的運(yùn)行信息進(jìn)行保存，比如主節(jié)點(diǎn)的replid。
4. 主節(jié)點(diǎn)執(zhí)行 bgsave 進(jìn)行 RDB 文件的持久化。這一步與第三步同時進(jìn)行，就算主節(jié)點(diǎn)已經(jīng)有RDB文件了，但是由于RDB的數(shù)據(jù)進(jìn)度是比較落后的，所以還是要重新生成一個。
5. 主節(jié)點(diǎn)發(fā)送 RDB 文件給從節(jié)點(diǎn)，從節(jié)點(diǎn)保存 RDB數(shù)據(jù)到本地硬盤。
6. 主節(jié)點(diǎn)將從生成 RDB 到接收完成期間執(zhí)行的寫命令，寫入緩沖區(qū)中，等從節(jié)點(diǎn)保存完 RDB 文件后，主節(jié)點(diǎn)再將緩沖區(qū)內(nèi)的數(shù)據(jù)補(bǔ)發(fā)給從節(jié)點(diǎn)，補(bǔ)發(fā)的數(shù)據(jù)仍然按照RDB的二進(jìn)制格式追加寫入到收到的 RDB文件中，保持主從一致性。
7. 從節(jié)點(diǎn)清空自身原有舊數(shù)據(jù)。
8. 從節(jié)點(diǎn)加載 RDB 文件得到與主節(jié)點(diǎn)一致的數(shù)據(jù)。
9. 如果從節(jié)點(diǎn)加載 RDB完成之后，開啟了 AOF持久化功能，它會進(jìn)行bgrewrite 重寫操作，因?yàn)樯厦孢@個過程從節(jié)點(diǎn)收到了大量數(shù)據(jù)，此時AOF也在同步記錄數(shù)據(jù)，此時進(jìn)行一次重寫，對剛才收到的數(shù)據(jù)進(jìn)行一個壓縮。

• 無硬盤模式

新版的Redis，對以上過程又做了優(yōu)化，主節(jié)點(diǎn)在生成RDB文件時，要把數(shù)據(jù)寫入文件，然后再把文件傳輸給從節(jié)點(diǎn)。而無硬盤模式下，主節(jié)點(diǎn)生成了RDB格式的數(shù)據(jù)后，不會寫入文件，而是直接發(fā)送給從節(jié)點(diǎn)。這樣就減少了大量硬盤IO，提高了同步效率。

從節(jié)點(diǎn)也相同，之前的從節(jié)點(diǎn)會把收到的RDB數(shù)據(jù)存儲到硬盤生成文件，然后再加載文件。無硬盤模式下，從節(jié)點(diǎn)直接加載網(wǎng)絡(luò)中的RDB數(shù)據(jù)，不再寫入硬盤。

---

部分同步

部分復(fù)制主要是 Redis 針對全量復(fù)制的過高開銷做出的一種優(yōu)化措施，使用 psync replicationld offset 命令實(shí)現(xiàn)。當(dāng)從節(jié)點(diǎn)正在復(fù)制主節(jié)點(diǎn)時，如果出現(xiàn)網(wǎng)絡(luò)閃斷或者命令丟失等異常情況時，從節(jié)點(diǎn)會向主節(jié)點(diǎn)要求補(bǔ)發(fā)丟失的命令數(shù)據(jù)，如果主節(jié)點(diǎn)的復(fù)制積壓緩沖區(qū)存在數(shù)據(jù)，則直接發(fā)送給從節(jié)點(diǎn)，這樣就可以保持主從節(jié)點(diǎn)復(fù)制的一致性。補(bǔ)發(fā)的這部分?jǐn)?shù)據(jù)一般遠(yuǎn)遠(yuǎn)小于全量數(shù)據(jù)，所以開銷很小。

部分復(fù)制流程如圖所示：

1. 當(dāng)主從節(jié)點(diǎn)之間出現(xiàn)網(wǎng)絡(luò)中斷時，如果超過repl-timeout 時間，主節(jié)點(diǎn)會認(rèn)為從節(jié)點(diǎn)故障并中斷復(fù)制連接。
2. 主從連接中斷期間，主節(jié)點(diǎn)依然響應(yīng)命令，但這些復(fù)制命令都因網(wǎng)絡(luò)中斷無法及時發(fā)送給從節(jié)點(diǎn)，所以暫時將這些命令滯留在復(fù)制積壓緩沖區(qū)中。
3. 當(dāng)主從節(jié)點(diǎn)網(wǎng)絡(luò)恢復(fù)后，從節(jié)點(diǎn)再次連上主節(jié)點(diǎn)。
4. 從節(jié)點(diǎn)將之前保存的 replicationld 和 offset 作為 psync 的參數(shù)發(fā)送給主節(jié)點(diǎn)，請求進(jìn)行部分復(fù)制。
5. 主節(jié)點(diǎn)接到 psync 請求后，進(jìn)行必要的驗(yàn)證。隨后根據(jù) offset 去復(fù)制積壓緩沖區(qū)查找合適的數(shù)據(jù)并響應(yīng) +CONTINUE 給從節(jié)點(diǎn)。
6. 主節(jié)點(diǎn)將需要從節(jié)點(diǎn)同步的數(shù)據(jù)發(fā)送給從節(jié)點(diǎn)，最終完成一致性。

---

實(shí)時同步

主從節(jié)點(diǎn)在建立復(fù)制連接后，主節(jié)點(diǎn)會把自己收到的修改操作，通過 TCP 長連接的方式，源源不斷的傳輸給從節(jié)點(diǎn)，從節(jié)點(diǎn)就會根據(jù)這些請求來同時修改自身的數(shù)據(jù)，從而保持和主節(jié)點(diǎn)數(shù)據(jù)的一致性。

另外，這樣的長連接，需要通過心跳包的方式來維護(hù)連接狀態(tài)，(這里的心跳是指應(yīng)用層自己實(shí)現(xiàn)的心跳，而不是 TCP 自帶的心跳)。

1. 主從節(jié)點(diǎn)彼此都有心跳檢測機(jī)制，各自模擬成對方的客戶端進(jìn)行通信。
2. 主節(jié)點(diǎn)默認(rèn)每隔 10 秒對從節(jié)點(diǎn)發(fā)送 ping命令，判斷從節(jié)點(diǎn)的存活性和連接狀態(tài)。
3. 從節(jié)點(diǎn)默認(rèn)每隔1秒向主節(jié)點(diǎn)發(fā)送 replconfack{offset}命令，給主節(jié)點(diǎn)上報自身當(dāng)前的復(fù)制偏移重。

如果主節(jié)點(diǎn)發(fā)現(xiàn)從節(jié)點(diǎn)通信延遲超過repl-timeout配置的值(默認(rèn)60秒)，則判定從節(jié)點(diǎn)下線，斷開復(fù)制客戶端連接。從節(jié)點(diǎn)恢復(fù)連接后，心跳機(jī)制繼續(xù)進(jìn)行。

---

那么以上三種同步機(jī)制，和主從復(fù)制有什么關(guān)系？在整個主從同步的過程中，最后兩步分別是同步數(shù)據(jù)集和持續(xù)復(fù)制命令。

• 同步數(shù)據(jù)集：
  • 如果是第一次同步，觸發(fā)全量同步
  • 如果是斷線重連，觸發(fā)部分同步
• 持續(xù)復(fù)制命令：
  • 進(jìn)行實(shí)時同步

---

節(jié)點(diǎn)晉升

先前提及過很多次，從節(jié)點(diǎn)是可以晉升為主節(jié)點(diǎn)的，那么什么時候從節(jié)點(diǎn)會晉升？

這分情況，對于一般的主從復(fù)制，情況如下：

1. 主動斷開主從關(guān)系

用戶可以通過slaveof no one命令，斷開與主節(jié)點(diǎn)的連接，此時從節(jié)點(diǎn)斷開連接后，自動晉升為主節(jié)點(diǎn)。

2. 主節(jié)點(diǎn)崩潰

在一般的主從情況下，如果主節(jié)點(diǎn)崩潰，此時從節(jié)點(diǎn)不會自動晉升，需要用戶進(jìn)行手動操作。這是一個非常難辦的問題，因?yàn)榉?wù)器崩潰是不可預(yù)知的，如果大半夜服務(wù)崩潰了，此時程序員又不能及時重啟，就會造成很大麻煩。后續(xù)Redis引入了哨兵機(jī)制，處理這種情況下的自動晉升。

---