我們?cè)谏a(chǎn)中使用 Redis，如果只部署一個(gè) Redis 實(shí)例，當(dāng)該實(shí)例宕機(jī)，到恢復(fù)之前都不可用；雖說(shuō) Redis 一般都用來(lái)做緩存，但不可用給業(yè)務(wù)系統(tǒng)帶來(lái)的影響也是不小的，流量大時(shí)甚至?xí)?dǎo)致整個(gè)服務(wù)宕機(jī)。所以 Redis 的高可用也非常重要，Redis 的高可用簡(jiǎn)單來(lái)說(shuō)就是增加冗余副本，將一份數(shù)據(jù)保存在多個(gè)實(shí)例上；即使有一個(gè)實(shí)例宕機(jī)，其他服務(wù)仍然可以對(duì)外提供服務(wù)，不影響業(yè)務(wù)使用。

一. Redis 主從同步

Redis 提供了主從模式（一主多從）來(lái)提高 Redis 的可用性，主從庫(kù)之間采用的是讀寫(xiě)分離：

• 讀操作：主從庫(kù)都能接收

• 寫(xiě)操作：主庫(kù)能接收，執(zhí)行完后同步給從庫(kù)

主從同步原理

首次全量同步

主從第一次同步會(huì)經(jīng)歷三個(gè)步驟：

（1）主從庫(kù)建立連接，二者連接完成后開(kāi)始同步。

（2）首次同步需要全量數(shù)據(jù)，主庫(kù)會(huì) fork 出一個(gè)子進(jìn)程來(lái)生成 RDB 快照，接著將 RDB 文件發(fā)送給從庫(kù)（不會(huì)阻塞主線程），從庫(kù)收到后清空舊數(shù)據(jù)，最后加載 RDB 文件完成全量數(shù)據(jù)同步。

（3）在主庫(kù)生成 RDB 后接收的命令會(huì)暫存到一塊內(nèi)存區(qū)域：replication buffer，當(dāng)從庫(kù)加載完 RDB 快照后，再將這塊暫存的數(shù)據(jù)發(fā)送給從庫(kù)執(zhí)行，最終完成首次主從同步。

為什么要單獨(dú)維護(hù)全量同步階段的增量數(shù)據(jù)呢？

• 單獨(dú)維護(hù)是為了保證命令執(zhí)行的順序性，這批增量數(shù)據(jù)需要等到 RDB 文件加載完后再發(fā)送給從庫(kù)，否則會(huì)因?yàn)橄群箜樞虿煌瑢?dǎo)致主從不一致。

當(dāng)完成首次同步后，主從之間維護(hù)一個(gè)長(zhǎng)連接，后續(xù)寫(xiě)命令通過(guò)這個(gè)長(zhǎng)連接進(jìn)行同步。

長(zhǎng)連接因?yàn)榫W(wǎng)絡(luò)問(wèn)題斷開(kāi)了期間的寫(xiě)命令會(huì)丟嗎？

• 當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)導(dǎo)致長(zhǎng)連接斷開(kāi)，主庫(kù)也會(huì)將寫(xiě)命令暫存到一塊環(huán)形的內(nèi)存區(qū)域，等待連接恢復(fù)后將暫存的寫(xiě)命令發(fā)送給從庫(kù)，保證主從一致。

做主從復(fù)制的作用是？

數(shù)據(jù)冗余：主從復(fù)制實(shí)現(xiàn)了數(shù)據(jù)的熱備份；

高可用：當(dāng)主節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí)，可以由從節(jié)點(diǎn)提供服務(wù)，實(shí)現(xiàn)快速的故障恢復(fù)；

負(fù)載均衡：在主從的模式下，配合讀寫(xiě)分離，可以大大提供 Redis 整體的吞吐量。

二. Redis 故障轉(zhuǎn)移

主從模式能做到數(shù)據(jù)備份，也能支持讀寫(xiě)分離，但一旦主節(jié)點(diǎn)宕機(jī)，需要人工介入切換主節(jié)點(diǎn)。

Redis 提供了哨兵機(jī)制保證 Master 出現(xiàn)故障時(shí)自動(dòng)進(jìn)行主從切換，也就是故障轉(zhuǎn)移。

哨兵機(jī)制

哨兵節(jié)點(diǎn)的作用分為三點(diǎn)：監(jiān)控，選主，通知；一般哨兵會(huì)集群部署，原因是為了保證哨兵的高可用和防止下線誤判（下線誤判在下面分析）。

哨兵實(shí)現(xiàn)故障轉(zhuǎn)移原理

1. 哨兵監(jiān)控

Sentinel 節(jié)點(diǎn)會(huì)監(jiān)控 matser、slave 及其他 Sentinel 節(jié)點(diǎn)的狀態(tài)。這個(gè)是通過(guò) Redis 自身的 pub/sub 機(jī)制實(shí)現(xiàn)的。Redis 的哨兵一共有三個(gè)定時(shí)監(jiān)控任務(wù)，來(lái)完成節(jié)點(diǎn)的發(fā)現(xiàn)與監(jiān)控。

• 監(jiān)控主從拓?fù)湫畔?/span>：每隔 10 s，每個(gè) Sentinel 節(jié)點(diǎn)會(huì)向主從庫(kù)發(fā)送 info 命令，來(lái)獲取最新的拓?fù)浣Y(jié)構(gòu)；

• Sentinel 集群節(jié)點(diǎn)之間交換信息：每隔 2 s，每個(gè) Sentinel 節(jié)點(diǎn)會(huì)向 _sentinel_:hello 頻道上發(fā)送自身的信息，以及對(duì)主節(jié)點(diǎn)的判斷信息。這樣，Sentinel 節(jié)點(diǎn)之間就可以交換信息。

• 節(jié)點(diǎn)狀態(tài)監(jiān)控：每隔 1 s，每個(gè) Sentinel 節(jié)點(diǎn)會(huì)向 master、slave 及其他 Sentinel 節(jié)點(diǎn)發(fā)送 ping 命令做心跳檢測(cè)（服務(wù)端回復(fù) pong 代表節(jié)點(diǎn)正常），來(lái)判斷這些節(jié)點(diǎn)是否可達(dá)。

2. 主觀下線

Sentinel 每隔 1 s 會(huì)對(duì)數(shù)據(jù)節(jié)點(diǎn)發(fā)送 ping 命令做心跳檢測(cè)，當(dāng)節(jié)點(diǎn)超過(guò) down-after-milliseconds 沒(méi)有進(jìn)行回復(fù)，Sentinel 會(huì)對(duì)該節(jié)點(diǎn)做失敗判定，這個(gè)行為被稱(chēng)作主觀下線。

主觀下線，顧名思義是主觀的，可能會(huì)誤判，假設(shè)主觀下線后就進(jìn)行主從切換，實(shí)際主庫(kù)并沒(méi)有發(fā)生故障，后續(xù)的選主和通知操作會(huì)帶來(lái)額外的開(kāi)銷(xiāo)。

發(fā)生誤判的場(chǎng)景：網(wǎng)絡(luò)擁塞、節(jié)點(diǎn)發(fā)生短暫網(wǎng)絡(luò)分區(qū)，或是節(jié)點(diǎn)壓力較大響應(yīng)超時(shí)。

3. 客觀下線

為了防止下線誤判，只有當(dāng)大多數(shù)的哨兵節(jié)點(diǎn)認(rèn)為 master 下線才算真正下線，這個(gè)行為叫做客觀下線。

客觀下線過(guò)程：

（1） 當(dāng)某個(gè) Sentinel 節(jié)點(diǎn)發(fā)生判斷主庫(kù)“主觀下線”后，會(huì)給其他哨兵實(shí)例發(fā)送 is-master-down-by-addr 命令，其他哨兵節(jié)點(diǎn)會(huì)根據(jù)自己和主庫(kù)的連接情況，做出 Y（贊同）或 N（反對(duì)）的響應(yīng)。

（2） 當(dāng)哨兵獲取到了“客觀下線”所需的贊成票數(shù)后，就可以標(biāo)記主庫(kù)為“客觀下線”，這個(gè)所需要的票數(shù)由 quorum 配置項(xiàng)決定（例如，現(xiàn)在有 5 個(gè)哨兵，quorum 為 2，當(dāng)兩個(gè)哨兵判斷主服務(wù)器下線后則觸發(fā)故障轉(zhuǎn)移）。

4.Sentinel Leader 選舉

當(dāng)發(fā)生了客觀下線后，哨兵節(jié)點(diǎn)集群就會(huì)選出一個(gè) Leader 來(lái)進(jìn)行實(shí)際的故障轉(zhuǎn)移操作。Redis 使用 Raft 算法來(lái)實(shí)現(xiàn)哨兵領(lǐng)導(dǎo)者的選舉，大致過(guò)程如下：

（1）哨兵節(jié)點(diǎn)設(shè)置主服務(wù)器為“客觀下線”后，向其他哨兵節(jié)點(diǎn)發(fā)送命令，表明希望自己來(lái)執(zhí)行主從切換，其他哨兵節(jié)點(diǎn)會(huì)進(jìn)行投票。

（2）當(dāng)哨兵節(jié)點(diǎn)拿到半數(shù)以上的贊成票且票數(shù)大于等于哨兵配置文件中的 quorum 值就會(huì)成為 Leader。

Leader 選舉的投票邏輯很簡(jiǎn)單：在這一輪投票中，如果沒(méi)有投過(guò)票就回復(fù)同意，如果投過(guò)票就回復(fù)拒絕。

（3）如果此過(guò)程沒(méi)有選出 Leader 則會(huì)等待故障超時(shí)間的 2 倍時(shí)長(zhǎng)，然后進(jìn)入下一輪選舉。

什么情況會(huì)選不出 Leader？

哨兵集群能夠成功投票，很大程度上取決于正常的網(wǎng)絡(luò)傳輸。如果網(wǎng)絡(luò)壓力大或短暫阻塞就可能導(dǎo)致沒(méi)有哨兵節(jié)點(diǎn)拿到半數(shù)以上的票。而網(wǎng)絡(luò)問(wèn)題一般都會(huì)持續(xù)一小段時(shí)間，所以在沒(méi)有選出 Leader 后會(huì)等待一段時(shí)間再進(jìn)入下一輪。

5. 故障轉(zhuǎn)移

選出哨兵的 Leader 后就會(huì)進(jìn)行故障轉(zhuǎn)移，也就是從 slave 中選出一個(gè)新 master 替換故障 master，主要有以下判斷標(biāo)準(zhǔn)：

（1）跟 master 斷開(kāi)鏈接的時(shí)長(zhǎng)：如果一個(gè) slave 和 master 的斷開(kāi)鏈接時(shí)長(zhǎng)已經(jīng)超過(guò) down-after-milliseconds 的 10 倍，那哨兵就會(huì)認(rèn)為該 slave 不適合被選為 master。

（2）slave 的優(yōu)先級(jí)配置：slave priority 參數(shù)越小，優(yōu)先級(jí)越高。

（3）主從復(fù)制進(jìn)度：當(dāng) 優(yōu)先級(jí) 相同時(shí)，哪個(gè) slave 和 master 的數(shù)據(jù)越接近，優(yōu)先級(jí)越高。

（4）run id：如果 優(yōu)先級(jí)配置 和 主從復(fù)制進(jìn)度 都相同，則哪個(gè) slave 的 run id 越小，優(yōu)先級(jí)越高。

選出 master 后，對(duì)它執(zhí)行 slaveof no one 命令讓其成為主節(jié)點(diǎn)，并對(duì)剩余 slave 節(jié)點(diǎn)發(fā)送命令讓他們成為新 master 的從節(jié)點(diǎn)，最后和其他哨兵節(jié)點(diǎn)交換信息完成故障轉(zhuǎn)移。

主從切換過(guò)程中，是否能對(duì)外正常提供讀寫(xiě)服務(wù)？

如果采用讀寫(xiě)分離，還是可以正常處理讀請(qǐng)求，但是對(duì)于寫(xiě)請(qǐng)求，服務(wù)端就無(wú)法處理了。如果需要應(yīng)對(duì)寫(xiě)請(qǐng)求，業(yè)務(wù)系統(tǒng)中可以將寫(xiě)緩存的操作改成異步或放到隊(duì)列處理。

腦裂問(wèn)題

如果碰巧客觀下線也誤判會(huì)發(fā)生什么？

會(huì)發(fā)生腦裂。

腦裂就是在主從集群中同時(shí)有兩個(gè)主節(jié)點(diǎn)，他們都能接收寫(xiě)請(qǐng)求。而不同的客戶(hù)端會(huì)往不同的主節(jié)點(diǎn)上寫(xiě)數(shù)據(jù)，甚至導(dǎo)致數(shù)據(jù)丟失。

Redis 的腦裂一般發(fā)生在主從切換時(shí)原主庫(kù)假故障的場(chǎng)景下：

當(dāng)主庫(kù)因?yàn)橐恍┰驘o(wú)法處理哨兵節(jié)點(diǎn)的心跳檢測(cè)時(shí)，就會(huì)被判定為“客觀下線”，接著就會(huì)進(jìn)行主從切換，但在主從切換完成之前，原主庫(kù)又恢復(fù)服務(wù)，就又會(huì)處理寫(xiě)請(qǐng)求，當(dāng)主從切換完成后通知客戶(hù)端之前就會(huì)有兩個(gè)主節(jié)點(diǎn)，即發(fā)生腦裂。

Redis 的腦裂可能會(huì)造成數(shù)據(jù)丟失，根本原因是 Redis 內(nèi)部沒(méi)有通過(guò)共識(shí)算法來(lái)維護(hù)多個(gè)數(shù)據(jù)節(jié)點(diǎn)的強(qiáng)一致性，因?yàn)閺?qiáng)一致性的成本太大，而 Redis 主打性能，所以 Redis 放棄 C（一致性） 而選擇 A（可用性）。