主從復(fù)制

主從復(fù)制是 Redis 高可用服務(wù)最基礎(chǔ)的保證，將一臺(tái) Redis 主服務(wù)器，同步數(shù)據(jù)到多臺(tái) Redis 從服務(wù)器上，即一主多從的模式，且主從服務(wù)器之間采用的是「讀寫分離」的方式。

主服務(wù)器可以進(jìn)行讀寫操作，當(dāng)發(fā)生寫操作時(shí)，自動(dòng)將寫操作同步給從服務(wù)器，而從服務(wù)器一般是只讀，并接收主服務(wù)器同步過來的寫操作命令，然后執(zhí)行這條命令。

我們可以使用 replicaof（Redis 5.0 之前使用 slaveof）命令形成主服務(wù)器和從服務(wù)器的關(guān)系。

// 服務(wù)器B執(zhí)行這條命令
replicaof <服務(wù)器A的IP地址> <服務(wù)器A的Redis端口號(hào)>

主從復(fù)制共有三種模式：全量復(fù)制、基于長(zhǎng)連接的命令傳播、增量復(fù)制。

主從服務(wù)器第一次同步的時(shí)候，就是采用全量復(fù)制，此時(shí)主服務(wù)器會(huì)兩個(gè)耗時(shí)的地方，分別是生成 RDB 文件和傳輸 RDB 文件。

1. 建立鏈接、協(xié)商同步。給全量復(fù)制做準(zhǔn)備
2. 主服務(wù)器同步數(shù)據(jù)給從服務(wù)器。主服務(wù)器會(huì)執(zhí)行 bgsave 命令來生成 RDB 文件，然后把文件發(fā)送給從服務(wù)器。從服務(wù)器收到 RDB 文件后，會(huì)先清空當(dāng)前的數(shù)據(jù)，然后載入 RDB 文件
3. 主服務(wù)器發(fā)送新的寫操作命令給從服務(wù)器。為了保證主從服務(wù)器的數(shù)據(jù)一致性，主服務(wù)器將 bgsave 期間收到的寫操作命令，寫入到 replication buffer 緩沖區(qū)里。在主服務(wù)器生成的 RDB 文件發(fā)送完，從服務(wù)器完成 RDB 文件的載入后，會(huì)回復(fù)一個(gè)確認(rèn)消息給主服務(wù)器。接著，主服務(wù)器將 replication buffer 緩沖區(qū)里所記錄的寫操作命令發(fā)送給從服務(wù)器，從服務(wù)器執(zhí)行命令，這時(shí)主從服務(wù)器的數(shù)據(jù)就一致了

為了避免過多的從服務(wù)器和主服務(wù)器進(jìn)行全量復(fù)制，可以把一部分從服務(wù)器升級(jí)為「經(jīng)理角色」，讓它也有自己的從服務(wù)器，分?jǐn)傊鞣?wù)器的壓力。

在「從服務(wù)器」上執(zhí)行下面這條命令，使其作為目標(biāo)服務(wù)器的從服務(wù)器。如果目標(biāo)服務(wù)器本身也是「從服務(wù)器」，那么該目標(biāo)服務(wù)器就會(huì)成為「經(jīng)理角色」，不僅可以接收主服務(wù)器同步的數(shù)據(jù)，也會(huì)把數(shù)據(jù)同步給自己旗下的從服務(wù)器，從而減輕主服務(wù)器的負(fù)擔(dān)。

replicaof <目標(biāo)服務(wù)器的IP> 6379

第一次同步完成后，主從服務(wù)器會(huì)維護(hù)著一個(gè)長(zhǎng)連接，主服務(wù)器在接收到寫操作命令后，會(huì)通過這個(gè)連接將寫命令傳播給從服務(wù)器，來保證主從服務(wù)器的數(shù)據(jù)一致性。

如果遇到網(wǎng)絡(luò)異常中斷，導(dǎo)致無法進(jìn)行命令傳播時(shí)，就利用 repl_backlog_size 緩沖區(qū)進(jìn)行增量復(fù)制，實(shí)現(xiàn)主從服務(wù)器的數(shù)據(jù)一致性。

哨兵模式

在使用 Redis 主從服務(wù)時(shí)，當(dāng) Redis 的主從服務(wù)器出現(xiàn)故障宕機(jī)，需要進(jìn)行手動(dòng)恢復(fù)。

為了解決這個(gè)問題，Redis 增加了哨兵模式（Redis Sentinel），哨兵模式做到了可以監(jiān)控主從服務(wù)器，并且提供主從節(jié)點(diǎn)故障轉(zhuǎn)移的功能。

如果主節(jié)點(diǎn)或者從節(jié)點(diǎn)沒有在規(guī)定的時(shí)間內(nèi)響應(yīng)哨兵的 PING 命令，哨兵就會(huì)將它們標(biāo)記為「主觀下線」。這個(gè)「規(guī)定的時(shí)間」是由配置項(xiàng) down-after-milliseconds 參數(shù)設(shè)定的，單位是毫秒。

同時(shí)針對(duì)「主節(jié)點(diǎn)」，設(shè)計(jì)「主觀下線」和「客觀下線」兩個(gè)狀態(tài)，客觀下線只適用于主節(jié)點(diǎn)。因?yàn)橛锌赡堋钢鞴?jié)點(diǎn)」其實(shí)并沒有故障，只是因?yàn)橹鞴?jié)點(diǎn)的系統(tǒng)壓力比較大或者網(wǎng)絡(luò)擁塞，導(dǎo)致主節(jié)點(diǎn)沒有在規(guī)定時(shí)間內(nèi)響應(yīng)哨兵的 PING 命令。

所以，為了減少誤判，哨兵在部署時(shí)會(huì)用多個(gè)節(jié)點(diǎn)部署成哨兵集群（最少需要三臺(tái)機(jī)器來部署哨兵集群），通過多個(gè)哨兵節(jié)點(diǎn)一起判斷，就可以避免因?yàn)閱蝹€(gè)哨兵自身網(wǎng)絡(luò)狀況不好，導(dǎo)致誤判主節(jié)點(diǎn)下線的情況。同時(shí)，多個(gè)哨兵的網(wǎng)絡(luò)同時(shí)不穩(wěn)定的概率較小，由它們一起做決策，誤判率也能降低。

當(dāng)一個(gè)哨兵判斷主節(jié)點(diǎn)「主觀下線」后，就會(huì)向其他哨兵發(fā)起命令，其他哨兵收到這個(gè)命令后，就會(huì)根據(jù)自身和主節(jié)點(diǎn)的網(wǎng)絡(luò)狀況，做出贊成投票或者拒絕投票的響應(yīng)。

當(dāng)這個(gè)哨兵的贊同票數(shù)達(dá)到配置文件中的 quorum 配置項(xiàng)設(shè)定的值后，主節(jié)點(diǎn)就會(huì)被該哨兵標(biāo)記為「客觀下線」。

哨兵判斷完主節(jié)點(diǎn)客觀下線后，就要開始在多個(gè)「從節(jié)點(diǎn)」中，選出一個(gè)從節(jié)點(diǎn)來做新主節(jié)點(diǎn)。這時(shí)候，還需要在哨兵集群中選出一個(gè) leader，讓 leader 來執(zhí)行主從切換。

選舉 leader 的過程其實(shí)也是一個(gè)投票的過程，在投票開始前，是哪個(gè)哨兵節(jié)點(diǎn)判斷主節(jié)點(diǎn)為「客觀下線」，這個(gè)哨兵節(jié)點(diǎn)就是候選者，所謂的候選者，就是想當(dāng) leader 的哨兵。

候選者會(huì)向其他哨兵發(fā)送命令，表明希望成為 leader 來執(zhí)行主從切換，并讓其他哨兵對(duì)它進(jìn)行投票。每個(gè)哨兵只有一次投票機(jī)會(huì)，如果用完就不能再參與投票了，可以投給自己或投給別人，但是只有候選者才能把票投給自己。

舉例來說，假設(shè)哨兵節(jié)點(diǎn)有 3 個(gè)，quorum 設(shè)置為 2，那么任何一個(gè)想成為 leader 的哨兵只要拿到 2 張贊成票，就可以選舉成功了。如果沒有滿足條件，就需要重新進(jìn)行選舉。

選舉出哨兵 leader 后，就可以進(jìn)行主從故障轉(zhuǎn)移的過程了。

1. 在已下線的主節(jié)點(diǎn)（舊主節(jié)點(diǎn)）下屬的所有「從節(jié)點(diǎn)」里，挑選出一個(gè)從節(jié)點(diǎn)，并將其轉(zhuǎn)換為主節(jié)點(diǎn)（根據(jù)節(jié)點(diǎn)的優(yōu)先級(jí)、復(fù)制進(jìn)度、ID 號(hào)，盡可能讓數(shù)據(jù)最全的節(jié)點(diǎn)成為新主節(jié)點(diǎn)）
2. 讓已下線的主節(jié)點(diǎn)下屬的所有「從節(jié)點(diǎn)」修改復(fù)制目標(biāo)，修改為復(fù)制「新主節(jié)點(diǎn)」
3. 將新主節(jié)點(diǎn)的 IP 地址和信息，通過「發(fā)布/訂閱機(jī)制」通知給客戶端
4. 繼續(xù)監(jiān)視舊主節(jié)點(diǎn)，等這個(gè)舊主節(jié)點(diǎn)重新上線時(shí)，將它設(shè)置為新主節(jié)點(diǎn)的從節(jié)點(diǎn)

集群腦裂

在 Redis 主從架構(gòu)中，假設(shè)主節(jié)點(diǎn)網(wǎng)絡(luò)突然發(fā)生了問題，它與所有的從節(jié)點(diǎn)都失聯(lián)了，但是和客戶端的網(wǎng)絡(luò)還是正常的?？蛻舳瞬⒉恢?Redis 內(nèi)部已經(jīng)出現(xiàn)了問題，繼續(xù)向主節(jié)點(diǎn)寫數(shù)據(jù)，因?yàn)橹鲝墓?jié)點(diǎn)之間的網(wǎng)絡(luò)問題，這些數(shù)據(jù)始終無法同步給從節(jié)點(diǎn)。

這時(shí)，哨兵也發(fā)現(xiàn)主節(jié)點(diǎn)失聯(lián)，它就認(rèn)為主節(jié)點(diǎn)掛了（但實(shí)際上主節(jié)點(diǎn)還是正常運(yùn)行，只是網(wǎng)絡(luò)出問題了），于是哨兵就會(huì)在「從節(jié)點(diǎn)」中選舉出一個(gè)新主節(jié)點(diǎn)，這時(shí)集群就有兩個(gè)主節(jié)點(diǎn)了 —— 腦裂出現(xiàn)了（相當(dāng)于出現(xiàn)了兩個(gè)大腦）。

過了一會(huì)，主節(jié)點(diǎn)網(wǎng)絡(luò)突然好了，重新上線時(shí)，因?yàn)樯诒耙呀?jīng)選舉出了一個(gè)新主節(jié)點(diǎn)，就會(huì)把舊主節(jié)點(diǎn)降級(jí)為從節(jié)點(diǎn)，然后從節(jié)點(diǎn)會(huì)向新主節(jié)點(diǎn)請(qǐng)求數(shù)據(jù)同步。

因?yàn)榈谝淮瓮绞侨客?#xff0c;從節(jié)點(diǎn)會(huì)清空本地的數(shù)據(jù)，再做全量同步。所以，之前客戶端寫入的數(shù)據(jù)就會(huì)丟失。

簡(jiǎn)單來說，由于網(wǎng)絡(luò)問題，集群節(jié)點(diǎn)之間失去聯(lián)系，主從數(shù)據(jù)不同步，哨兵重新平衡選舉后產(chǎn)生兩個(gè)主服務(wù)。等網(wǎng)絡(luò)恢復(fù)后，舊主節(jié)點(diǎn)會(huì)降級(jí)為從節(jié)點(diǎn)，再與新主節(jié)點(diǎn)進(jìn)行同步復(fù)制時(shí)，由于從節(jié)點(diǎn)會(huì)清空自己的緩沖區(qū)，導(dǎo)致之前客戶端寫入的數(shù)據(jù)丟失。

解決方案

當(dāng)主節(jié)點(diǎn)發(fā)現(xiàn)從節(jié)點(diǎn)下線或者通信超時(shí)的總數(shù)量達(dá)到閾值時(shí)，禁止寫數(shù)據(jù)，直接返回錯(cuò)誤給客戶端。

在 Redis 配置文件中，有兩個(gè)參數(shù)可以設(shè)置。

• min-slaves-to-write x，主節(jié)點(diǎn)必須要有至少 x 個(gè)從節(jié)點(diǎn)連接，如果小于這個(gè)數(shù)，主節(jié)點(diǎn)就會(huì)禁止寫數(shù)據(jù)
• min-slaves-max-lag x，主從數(shù)據(jù)復(fù)制和同步的延遲不能超過 x 秒，如果超過，主節(jié)點(diǎn)就會(huì)禁止寫數(shù)據(jù)

可以把這兩個(gè)配置項(xiàng)搭配起來使用，分別給它們?cè)O(shè)置一定的閾值，假設(shè)為 N 和 T。即主庫(kù)連接的從庫(kù)中至少有 N 個(gè)從庫(kù)，且和主庫(kù)進(jìn)行數(shù)據(jù)復(fù)制時(shí)的 ACK 消息延遲不能超過 T 秒，否則主庫(kù)就不會(huì)再接收客戶端的寫請(qǐng)求了。

等到選舉出新主庫(kù)時(shí)，只有新主庫(kù)能接收和處理客戶端請(qǐng)求，此時(shí)新寫的數(shù)據(jù)會(huì)直接寫到新主庫(kù)中。而原主庫(kù)會(huì)被哨兵降為從庫(kù)，即使它的數(shù)據(jù)被清空了，也不會(huì)有數(shù)據(jù)丟失的問題。