淺談Redis Replication復(fù)制基本原理
這里就Redis Replication復(fù)制功能的基本原理進(jìn)行介紹
舊版復(fù)制的基本原理
在Redis 2.8版本之前，其復(fù)制功能大體可以分為兩種操作：「同步、傳播命令」。前者用于將Slave的數(shù)據(jù)庫狀態(tài)更新到Master的數(shù)據(jù)庫狀態(tài)。具體地，當(dāng)客戶端向Slave發(fā)送SLAVEOF命令，要求Slave復(fù)制Master時，Slave即會執(zhí)行同步操作。基本流程如下所示
Slave向Master發(fā)送SYNC命令 Master在收到SYNC命令后開始執(zhí)行BGSAVE命令，在后臺創(chuàng)建RDB文件。同時會使用一個緩沖區(qū)，用于記錄、保存在創(chuàng)建RDB文件期間所有的寫命令 當(dāng)Master的BGSAVE命令執(zhí)行完畢后，Master會將RDB文件發(fā)送給Slave。Slave接收、載入該RDB文件 Master將緩沖區(qū)中的所有寫命令發(fā)送給Slave，Slave接收、執(zhí)行所有寫命令 至此，Slave的數(shù)據(jù)庫狀態(tài)就更新到了Master的數(shù)據(jù)庫狀態(tài)。即Slave完成了同步
而后者則用于在主從同步建立后，Master每次收到、執(zhí)行完客戶端新的寫命令后。會將該寫命令傳播、發(fā)送至Slave。以保證主從的數(shù)據(jù)一致性
新版復(fù)制的基本原理
但舊版復(fù)制的實(shí)現(xiàn)存在一個嚴(yán)重的缺陷。當(dāng)主從之間一旦由于網(wǎng)絡(luò)中斷而斷開連接、停止復(fù)制，而一定時間后Slave通過自動重連恢復(fù)了與Master的網(wǎng)絡(luò)通訊。由于此時Slave已經(jīng)滯后于Master了，故其會向Master再次發(fā)送SYNC命令以重新開始從頭同步。顯然即使主從斷開的時間不長，二者之間可能也只是滯后了幾條數(shù)據(jù)。但Master依然還是需要對數(shù)據(jù)庫的全部數(shù)據(jù)創(chuàng)建RDB文件，然后發(fā)送給Slave。此舉的效率大大降低
故從Redis 2.8版本開始，其引入了PSYNC命令用于替代此前的SYNC命令，實(shí)現(xiàn)對「同步」操作進(jìn)行優(yōu)化。PSYNC命令具有完整重同步、部分重同步兩種模式。對于前者而言其基本原理與SYNC命令類似，通過Master向Slave發(fā)送其創(chuàng)建的RDB文件、緩沖區(qū)中的寫命令來實(shí)現(xiàn)；而對于后者而言，其適用于Slave斷線重連的場景。Master只需將斷線期間的寫命令再次發(fā)送給Slave即可，而無需去執(zhí)行非常消耗資源的RDB文件創(chuàng)建工作
顯然一旦Master、Slave同步完成后，后續(xù)Master在每次收到、執(zhí)行完客戶端新的寫命令后，只需將該寫命令傳播、發(fā)送至Slave即可。以時刻保證二者之間的數(shù)據(jù)一致性
PSYNC命令的基本原理
Replication Offset 復(fù)制偏移量
在PSYNC命令中引入了「Replication Offset復(fù)制偏移量」的概念，包括Master的復(fù)制偏移量、Slave的復(fù)制偏移量。每次當(dāng)Master向Slave傳播N個字節(jié)的數(shù)據(jù)命令時，Master就會將自身的復(fù)制偏移量加上N；每次當(dāng)Slave從Master接收到N個字節(jié)的數(shù)據(jù)后，Slave就會將自身的復(fù)制偏移量加上N。這樣只需對比Master、Slave的復(fù)制偏移量，即可知道二者之間是否處于一致的狀態(tài)。具體地來說，當(dāng)二者之間的復(fù)制偏移量完全一樣，則說明二者的數(shù)據(jù)狀態(tài)是一致的；反之則說明二者的數(shù)據(jù)狀態(tài)不一致
例如，Master的復(fù)制偏移量為255，Slave A的復(fù)制偏移量為255，Slave B的復(fù)制偏移量為200。此時說明：Master、Slave A之間的數(shù)據(jù)狀態(tài)是一致的；Master、Slave B之間的數(shù)據(jù)狀態(tài)則不一致。那么要讓Slave B與Master保持一致，Master只需再次向Slave B補(bǔ)傳后者所缺失的55(255-200)個字節(jié)的數(shù)據(jù)即可
Replication Backlog 復(fù)制積壓緩沖區(qū)
為了能夠?qū)崿F(xiàn)Master對Slave B補(bǔ)傳數(shù)據(jù)，就需要在Master中引入一個「Replication Backlog復(fù)制積壓緩沖區(qū)」的概念。其是Master中的一個固定長度的FIFO隊(duì)列。每次Master向所有Slave傳播、發(fā)送命令的同時，也會將該命令寫入復(fù)制積壓緩沖區(qū)當(dāng)中。同時也會在復(fù)制積壓緩沖區(qū)記錄其中每個字節(jié)數(shù)據(jù)所對應(yīng)的偏移量。
這樣當(dāng)Slave斷線重連后，Slave會通過PSYNC命令向Master告知Slave自身的復(fù)制偏移量。Master即可根據(jù)Slave的復(fù)制偏移量offset確定是采用部分重同步、還是完整重同步。具體地
如果offset偏移量之后的數(shù)據(jù)(即從偏移量offset+1開始的數(shù)據(jù))依然存在于Master的復(fù)制積壓緩沖區(qū)當(dāng)中，則Master就可以進(jìn)行部分重同步，只需將保存在復(fù)制積壓緩沖區(qū)中offset偏移量之后的所有數(shù)據(jù)再次發(fā)送給Slave即可 如果offset偏移量之后的數(shù)據(jù)(即從偏移量offset+1開始的數(shù)據(jù))不存在于Master的復(fù)制積壓緩沖區(qū)當(dāng)中，則Master就只能Slave進(jìn)行完整重同步，以讓二者達(dá)到一致。因?yàn)閺?fù)制積壓緩沖區(qū)是固定長度的，其只能保存Master在最近一段時間內(nèi)的所有數(shù)據(jù)、命令。并不能保存無限期限的數(shù)據(jù)、命令
Redis服務(wù)端的運(yùn)行ID
事實(shí)上對于Redis服務(wù)端而言，無論是Master還是Slave。其在啟動運(yùn)行后，都會有一個唯一標(biāo)識——run ID(運(yùn)行ID)。當(dāng)Slave第一次與Master建立同步時，Master會將自身的運(yùn)行ID發(fā)送給Slave。Slave會把這個Master的run ID保存、記錄下來。這樣當(dāng)Slave斷線、重連后，會將之前保存的Master的run ID再次發(fā)送給目前連接到的Master
如果Master發(fā)現(xiàn)從Slave處接收到的run ID就是自己本身，那說明這個Slave在斷開之前連的就是自己。這樣Master就會繼續(xù)嘗試執(zhí)行部分重同步操作 反之則說明，Slave在斷開之前連接的Master 與 當(dāng)前正在連接的Master 并不是同一個。此時，Master就必須對Slave進(jìn)行完整重同步
PSYNC命令執(zhí)行流程
對于Slave而言：
如果Slave此前未進(jìn)行過任何復(fù)制操作 或 已經(jīng)執(zhí)行過了SLAVEOF NO ONE命令，那么Slave在開始一次新的復(fù)制時將會向Master發(fā)送PSYNC ? -1命令，主動請求Master進(jìn)行完整重同步 反之，Slave此前已經(jīng)復(fù)制過了某個Master。那么Slave在開始復(fù)制時會向Master發(fā)送PSYNC 命令。其中，runid是Slave上次復(fù)制的Master的run ID；offset則是Slave的復(fù)制偏移量。Master會根據(jù)上述兩個參數(shù)的情況來決定具體執(zhí)行何種同步。即是完整重同步、還是部分重同步
對于Master而言，其在接收到Slave的PSYNC命令，作出以下三種回復(fù)中的一種
「FULLRESYNC」 ：意為Master將會與Slave進(jìn)行完整重同步。其中，runid是Master的運(yùn)行ID。Slave會將其保存、記錄下來。以便下一次發(fā)送PSYNC命令時使用；offset則是Master當(dāng)前的復(fù)制偏移量，Slave會將該值用于初始化自身的復(fù)制偏移量 「+CONTINUE」 ：意為Master將會與Slave進(jìn)行部分重同步。此時Slave只需等待Master將自身所缺失的部分?jǐn)?shù)據(jù)發(fā)送過來即可 「-ERR」：意為Master版本低于2.8，無法識別PSYNC命令。此時Slave會發(fā)送SYNC命令，并與Master進(jìn)行完整重同步
心跳檢測機(jī)制
與此同時在Redis 2.8版本中也引入了心跳機(jī)制。即在命令傳播階段，Slave默認(rèn)會以每秒一次的頻率向Slave發(fā)送如下命令。其中offset是Slave的復(fù)制偏移量
REPLCONF ACK <offset>
即所謂的心跳機(jī)制，其意義有以下幾個方面：
「1. 檢查主從之間的網(wǎng)絡(luò)狀態(tài)」
Master如果長時間沒有接收到某個Slave發(fā)送的REPLCONF ACK命令，那么Master就知道其與該Slave的網(wǎng)絡(luò)連接存在異常
「2. 用于實(shí)現(xiàn)min-slaves配置項(xiàng)」
Redis的配置文件提供了min-slaves配置項(xiàng)以防止Master在不安全的情況下執(zhí)行寫命令，示例配置如下所示。如果期望禁用該功能，只需將min-slaves-to-write、min-slaves-max-lag任意一項(xiàng)設(shè)為0即可
# Master 在接受客戶端寫入命令時，所必需的可用Slave的最小數(shù)目要求
# 一旦可用Slave的數(shù)量低于該配置項(xiàng)值，則Master會拒絕執(zhí)行寫命令
min-slaves-to-write 3
# Master與Slave 之間網(wǎng)絡(luò)延遲(lag)的上限，Unit：秒
# 一旦某個Slave與Master的延遲超過該值，則Master會該Slave將視為不可用狀態(tài)
min-slaves-max-lag 10
「3. 檢測命令丟失」
Master傳播給Slave的命令可能會由于網(wǎng)絡(luò)原因?qū)е耂lave并未收到。而Slave通過REPLCONF ACK命令主動向Master上報(bào)自身當(dāng)前的復(fù)制偏移量。這樣Master即可主動發(fā)現(xiàn)傳播的命令是否發(fā)生了丟失，并利用復(fù)制積壓緩沖區(qū)對丟失的命令進(jìn)行補(bǔ)傳。由于REPLCONF ACK命令、復(fù)制積壓緩沖區(qū)都是2.8版本開始引入的。故在之前的版本中。即使命令在傳播過程中丟失了，Master、Slave均無法注意到。更無法進(jìn)行命令補(bǔ)傳
參考文獻(xiàn)
Redis設(shè)計(jì)與實(shí)現(xiàn) 黃健宏著