前言

大家好，我是田螺。

分享一道大廠面試真題：說(shuō)說(shuō)redis主從的腦裂？

我們可以按照這幾個(gè)維度來(lái)回答：

• 什么是腦裂行為
• 主從集群中為什么會(huì)發(fā)生腦裂？
• 腦裂為什么又會(huì)導(dǎo)致數(shù)據(jù)丟失呢？
• 我們?cè)撊绾伪苊夂蛻?yīng)對(duì)腦裂的發(fā)生呢？

1. 什么是腦裂

什么是腦裂行為?

• 腦裂（Split-Brain）是指在分布式系統(tǒng)中，網(wǎng)絡(luò)分區(qū)導(dǎo)致多個(gè)節(jié)點(diǎn)之間失去聯(lián)系，形成了兩個(gè)或多個(gè)獨(dú)立的“腦”，每個(gè)腦都認(rèn)為自己是主節(jié)點(diǎn)，導(dǎo)致數(shù)據(jù)寫入的沖突和不一致。

圖片

• 在 Redis 的主從架構(gòu)中，如果主節(jié)點(diǎn)和從節(jié)點(diǎn)因網(wǎng)絡(luò)故障或其他原因失去聯(lián)系，哨兵開始選舉了新的主節(jié)點(diǎn)，而舊的主節(jié)點(diǎn)恢復(fù)過來(lái)繼續(xù)接受寫請(qǐng)求，也就是存在兩個(gè)redis主節(jié)點(diǎn)了，這就是redis的腦裂行為。

2. 主從集群中為什么會(huì)發(fā)生腦裂？

腦裂行為在Redis主從集群中可能發(fā)生的原因，主要包括以下幾點(diǎn)：

圖片

• 網(wǎng)絡(luò)故障：在網(wǎng)絡(luò)故障或不穩(wěn)定的情況下，主節(jié)點(diǎn)與哨兵或從節(jié)點(diǎn)之間的通信可能會(huì)中斷。這時(shí)，哨兵可能會(huì)誤認(rèn)為主節(jié)點(diǎn)已宕機(jī)。
• 哨兵的選舉機(jī)制：當(dāng)哨兵無(wú)法與主節(jié)點(diǎn)通信時(shí)，會(huì)啟動(dòng)選舉過程，從現(xiàn)有的從節(jié)點(diǎn)中選出一個(gè)新的主節(jié)點(diǎn)。如果此時(shí)網(wǎng)絡(luò)恢復(fù)，主節(jié)點(diǎn)仍在運(yùn)行，就會(huì)導(dǎo)致出現(xiàn)兩個(gè)主節(jié)點(diǎn)。
• 假故障: 哨兵的故障轉(zhuǎn)移策略在網(wǎng)絡(luò)異常時(shí)會(huì)過于敏感，容易在錯(cuò)誤的情況下進(jìn)行主節(jié)點(diǎn)的選舉。也就是因?yàn)榧俟收蠈?dǎo)致又多選一個(gè)主節(jié)點(diǎn)出來(lái)。

3. 腦裂為什么又會(huì)導(dǎo)致數(shù)據(jù)丟失呢？

Redis的主從切換后，一旦從庫(kù)被提升為新的主庫(kù)，哨兵會(huì)指示原主庫(kù)去執(zhí)行主從復(fù)制命令，以便與新主庫(kù)進(jìn)行全量同步數(shù)據(jù)。最后在全量同步的階段的話，原主庫(kù)需要清除本地?cái)?shù)據(jù)，加載來(lái)自新主庫(kù)的RDB文件（我們知道，redis主從同步是基于rdb文件的）。這就會(huì)導(dǎo)致在主從切換期間，原主庫(kù)接收的新寫數(shù)據(jù)會(huì)丟失啦。

還是上個(gè)簡(jiǎn)單的圖，方便大家理解吧：

圖片

上圖，大家可以發(fā)現(xiàn)：

• 當(dāng)舊的主庫(kù)因?yàn)榧偎溃俟收希?的原因，導(dǎo)致哨兵開始選舉新的主庫(kù)。在選舉新主庫(kù)期間，舊的主庫(kù)莫名奇妙又好了，它可以繼續(xù)接受寫入的請(qǐng)求了。
• 然后新主庫(kù)選好了，就有兩個(gè)主庫(kù)在同時(shí)處理寫請(qǐng)求啦。等到新主庫(kù)選好之后，舊的主庫(kù)就變成從庫(kù)了，它需要從新的主庫(kù)那里同步數(shù)據(jù)過來(lái)，這樣一來(lái)，在切換期間，舊主庫(kù)保存的數(shù)據(jù)就丟失啦。

4. 我們?cè)撊绾伪苊?應(yīng)對(duì)腦裂的發(fā)生呢？

為了避免腦裂的發(fā)生，我們嘗試這些方法：

圖片

• 使用 Quorum 配置：確保哨兵數(shù)量為奇數(shù)，并設(shè)定適當(dāng)?shù)耐镀币?guī)則，以減少誤判的可能性。
• 合理設(shè)置超時(shí)參數(shù)：調(diào)整哨兵的 down-after-milliseconds 和 failover-timeout 參數(shù)，以適應(yīng)實(shí)際網(wǎng)絡(luò)環(huán)境，減少誤判。
• 網(wǎng)絡(luò)隔離與監(jiān)控：確保網(wǎng)絡(luò)穩(wěn)定，監(jiān)控網(wǎng)絡(luò)狀態(tài)和延遲，以便在問題出現(xiàn)時(shí)及時(shí)處理。
• 引入代理層：使用代理（如 Codis）來(lái)管理客戶端與 Redis 的連接，避免直接連接導(dǎo)致的腦裂。

還有個(gè)比較推薦的方式，那就是min-slaves-to-write 和 min-slaves-max-lag 這兩個(gè)參數(shù)，可以有效減少 Redis 腦裂的風(fēng)險(xiǎn)

• min-slaves-to-write：該參數(shù)設(shè)置在執(zhí)行寫操作時(shí)，至少需要有多少個(gè)從節(jié)點(diǎn)在線并且處于同步狀態(tài)。如果在線的從節(jié)點(diǎn)數(shù)量低于此值，主節(jié)點(diǎn)將拒絕寫入請(qǐng)求，從而避免在不一致的情況下進(jìn)行寫操作。
• min-slaves-max-lag：這個(gè)參數(shù)定義了允許的最大復(fù)制延遲（以秒為單位）。如果從節(jié)點(diǎn)的復(fù)制延遲超過此閾值，主節(jié)點(diǎn)將不會(huì)考慮這些從節(jié)點(diǎn)為有效，從而減少因落后節(jié)點(diǎn)引起的數(shù)據(jù)不一致問題。