1. 這篇文章真正要解決的問題如果你負(fù)責(zé)過 Redis 生產(chǎn)環(huán)境或者用 Redis 搭過主從加哨兵的架構(gòu)大概率碰到過一個(gè)非常詭異的現(xiàn)象主節(jié)點(diǎn)明明還在運(yùn)行日志里也沒有出現(xiàn)崩潰但業(yè)務(wù)卻突然寫入失敗或者部分?jǐn)?shù)據(jù)悄悄丟了。等你去查監(jiān)控發(fā)現(xiàn)“不分青紅皂白”地出現(xiàn)了一個(gè)新的主節(jié)點(diǎn)而原來的老主節(jié)點(diǎn)變成了一臺(tái)孤立的“光桿司令”。更讓人懵的是當(dāng)網(wǎng)絡(luò)恢復(fù)后老主節(jié)點(diǎn)仿佛被“降級(jí)”了一樣之前那幾分鐘寫入的數(shù)據(jù)全部沒了。你翻遍業(yè)務(wù)日志沒有發(fā)現(xiàn)任何顯式的報(bào)錯(cuò)數(shù)據(jù)就是沒了。這就是 Redis 腦裂Split Brain的典型表現(xiàn)。很多人第一次聽到“Redis 腦裂”第一反應(yīng)是是不是 Redis 有 Bug是不是哨兵Sentinel不靠譜是不是主從復(fù)制出了問題這里先給一個(gè)明確判斷Redis 腦裂不是 Redis 本身的 Bug也不是哨兵的隨機(jī)抽風(fēng)而是分布式系統(tǒng)中“網(wǎng)絡(luò)分區(qū) (Network Partition) 主備切換機(jī)制”共同作用下的必然結(jié)果。換句話說只要你用了 Redis 主從 哨兵模式又沒有對(duì)寫入方做任何保護(hù)腦裂就隨時(shí)可能發(fā)生。這不是概率問題而是時(shí)間問題。這篇文章我想把 Redis 腦裂這件事徹底講透。我會(huì)從主從架構(gòu)和哨兵的原理講起帶你看清楚腦裂發(fā)生的完整鏈路然后給你可以直接照做的排查命令、防腦裂配置和最佳實(shí)踐。如果你正在用 Redis 做緩存、做分布式鎖或者準(zhǔn)備在生產(chǎn)環(huán)境搭建 Redis 高可用集群這篇文章建議先收藏。腦裂等出問題時(shí)再學(xué)代價(jià)往往已經(jīng)不太小了。2. 什么是腦裂從現(xiàn)實(shí)場(chǎng)景理解分布式系統(tǒng)的“人格分裂”腦裂這個(gè)術(shù)語最早來自醫(yī)學(xué)指的是連接左右腦半球的胼胝體受損后左右腦各自為政人體出現(xiàn)“兩個(gè)意識(shí)”的狀態(tài)。在分布式系統(tǒng)里腦裂的含義類似一個(gè)集群中因?yàn)榫W(wǎng)絡(luò)分區(qū)、節(jié)點(diǎn)假死等原因原本只有一個(gè) Leader主節(jié)點(diǎn)的系統(tǒng)里同時(shí)出現(xiàn)了兩個(gè)或多個(gè)節(jié)點(diǎn)認(rèn)為自己是 Leader繼續(xù)對(duì)外提供服務(wù)。對(duì) Redis 來說腦裂的直接表現(xiàn)就是同一份數(shù)據(jù)同時(shí)有兩個(gè)主節(jié)點(diǎn)在寫。這里要區(qū)分一個(gè)概念Redis 腦裂并不是 Redis 主從復(fù)制本身壞了而是“容錯(cuò)切換決策”和“實(shí)際存活狀態(tài)”之間出現(xiàn)了不一致。2.1 為什么會(huì)出現(xiàn)兩個(gè)主節(jié)點(diǎn)Redis 主從模式下正常情況下只有一個(gè) master所有寫操作都走 master從節(jié)點(diǎn)slave/replica只同步數(shù)據(jù)不對(duì)外提供寫服務(wù)。當(dāng) master 出現(xiàn)故障時(shí)哨兵會(huì)發(fā)起故障轉(zhuǎn)移failover從從節(jié)點(diǎn)里選出一個(gè)新的 master。這個(gè)過程本身沒有錯(cuò)。但問題是哨兵是怎么判斷 master 故障的答案是“主觀下線”和“客觀下線”。這部分后面細(xì)講簡(jiǎn)單說就是如果 master 和哨兵之間的網(wǎng)絡(luò)斷了但 master 本身還在運(yùn)行比如還在接收客戶端的寫請(qǐng)求那么哨兵會(huì)主觀認(rèn)為 master 掛了然后發(fā)起故障轉(zhuǎn)移選出一個(gè)新 master。于是老 master 還在接受寫入。新 master 也在接受寫入。兩邊同時(shí)寫數(shù)據(jù)分叉。這就是腦裂。2.2 Redis 腦裂的本質(zhì)是 CAP 的取舍要真正理解腦裂不能只看 Redis 配置還要理解 CAP 理論。CAP 理論說的是一個(gè)分布式系統(tǒng)在網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)P你只能在一致性C和可用性A之間二選一。Redis 做主從切換追求的是高可用A當(dāng)主節(jié)點(diǎn)失聯(lián)時(shí)盡快選出新主讓業(yè)務(wù)不中斷。但代價(jià)是什么是可能犧牲一致性C在極端情況下舊主節(jié)點(diǎn)并沒有真正宕機(jī)它只是和哨兵網(wǎng)絡(luò)斷了用戶寫入的數(shù)據(jù)沒有同步到新主。所以更準(zhǔn)確的說法是Redis 腦裂不是故障而是 Redis 在“網(wǎng)絡(luò)分區(qū)高可用切換”場(chǎng)景下默認(rèn)選擇了“可用性優(yōu)先”的必然結(jié)果。理解這一點(diǎn)很重要因?yàn)樗鼪Q定了你不能用“加幾個(gè)哨兵”來解決腦裂而要從架構(gòu)設(shè)計(jì)層面去約束“舊主”的行為。3. Redis 主從架構(gòu)與哨兵腦裂出現(xiàn)前的基礎(chǔ)設(shè)施在深入腦裂機(jī)制之前必須先梳理 Redis 主從和哨兵的工作流程。很多人對(duì)腦裂的理解模糊其實(shí)是基礎(chǔ)概念不牢固。3.1 主從復(fù)制Master-Slave ReplicationRedis 主從復(fù)制的作用簡(jiǎn)單說就是把一臺(tái) Redis 節(jié)點(diǎn)的數(shù)據(jù)實(shí)時(shí)同步到其他節(jié)點(diǎn)。主節(jié)點(diǎn)master處理寫請(qǐng)求把寫操作記錄到自己的內(nèi)存并異步發(fā)送給從節(jié)點(diǎn)。從節(jié)點(diǎn)replica只處理讀請(qǐng)求接收主節(jié)點(diǎn)的同步數(shù)據(jù)保證和主節(jié)點(diǎn)最終一致。主從復(fù)制的核心步驟是從節(jié)點(diǎn)向主節(jié)點(diǎn)發(fā)送PSYNC命令請(qǐng)求同步。主節(jié)點(diǎn)執(zhí)行BGSAVE生成 RDB 快照同時(shí)把新寫入的命令記錄到復(fù)制緩沖區(qū)。主節(jié)點(diǎn)把 RDB 文件發(fā)送給從節(jié)點(diǎn)。從節(jié)點(diǎn)加載 RDB 文件后主節(jié)點(diǎn)繼續(xù)把復(fù)制緩沖區(qū)中的寫命令發(fā)給從節(jié)點(diǎn)。后續(xù)主節(jié)點(diǎn)每執(zhí)行一條寫命令都會(huì)實(shí)時(shí)發(fā)送給從節(jié)點(diǎn)。注意第 5 步Redis 的復(fù)制默認(rèn)是異步的。主節(jié)點(diǎn)執(zhí)行SET key value之后并不會(huì)等待從節(jié)點(diǎn)確認(rèn)“我已經(jīng)寫好了”而是直接返回給客戶端。這意味著什么意味著主節(jié)點(diǎn)上存在一段“最近寫入但還沒有同步到從節(jié)點(diǎn)”的數(shù)據(jù)窗口。一旦主節(jié)點(diǎn)在這時(shí)發(fā)生故障或切換這部分窗口數(shù)據(jù)就可能會(huì)丟失。3.2 哨兵Sentinel如何工作Sentinel 是 Redis 提供的高可用解決方案它的職責(zé)是監(jiān)控所有 Redis 節(jié)點(diǎn)的健康狀態(tài)。當(dāng)主節(jié)點(diǎn)出現(xiàn)問題時(shí)自動(dòng)執(zhí)行故障轉(zhuǎn)移從從節(jié)點(diǎn)中選出新的主。把新主節(jié)點(diǎn)的信息通知給客戶端。哨兵有幾個(gè)關(guān)鍵概念概念解釋主觀下線SDOWN單個(gè)哨兵發(fā)現(xiàn)主節(jié)點(diǎn)沒有在down-after-milliseconds時(shí)間內(nèi)響應(yīng)標(biāo)記為“主觀下線”客觀下線ODOWN多個(gè)哨兵達(dá)到 quorum 數(shù)量都認(rèn)為主節(jié)點(diǎn)下線則標(biāo)記為“客觀下線”故障轉(zhuǎn)移Failover客觀下線后哨兵們選出一個(gè) Leader 哨兵從從節(jié)點(diǎn)中選出新主并修改配置這里就出現(xiàn)了第一個(gè)容易被忽略的點(diǎn)主觀下線只需要一個(gè)哨兵就能觸發(fā)。它依據(jù)的是哨兵和主節(jié)點(diǎn)之間的網(wǎng)絡(luò)通信狀態(tài)而不是主節(jié)點(diǎn)本身的存活狀態(tài)。如果 Redis 主節(jié)點(diǎn)所在的服務(wù)器只是網(wǎng)絡(luò)暫時(shí)抖動(dòng)或者主節(jié)點(diǎn) CPU 負(fù)載過高導(dǎo)致無法及時(shí)響應(yīng) Ping但主節(jié)點(diǎn)本身還在正常運(yùn)行哨兵依然會(huì)判定它主觀下線。于是后面的事情就順理成章哨兵 A 發(fā)現(xiàn)主節(jié)點(diǎn) ping 不通標(biāo)記主觀下線。如果多個(gè)哨兵都收不到主節(jié)點(diǎn)的響應(yīng)達(dá)到 quorum標(biāo)記客觀下線。哨兵觸發(fā)故障轉(zhuǎn)移從從節(jié)點(diǎn)中選出新主。而客戶端那邊呢如果客戶端還連在舊主上寫操作依然會(huì)成功。兩個(gè)主節(jié)點(diǎn)同時(shí)工作的局面形成了。4. Redis 腦裂的完整觸發(fā)過程從網(wǎng)絡(luò)抖動(dòng)到數(shù)據(jù)丟失現(xiàn)在我們把上面的知識(shí)串起來完整走一遍 Redis 腦裂的生命周期。假設(shè)我們有這樣一個(gè)環(huán)境3 個(gè) Redis 節(jié)點(diǎn)1 個(gè) master、2 個(gè) replica。3 個(gè) Sentinel 實(shí)例。業(yè)務(wù)應(yīng)用通過哨兵獲取主節(jié)點(diǎn)地址連接 Redis。4.1 第一階段網(wǎng)絡(luò)分區(qū)發(fā)生假設(shè) Redis 主節(jié)點(diǎn)所在的機(jī)器因?yàn)榻粨Q機(jī)故障或者網(wǎng)絡(luò)擁塞和 Sentinel、從節(jié)點(diǎn)之間的網(wǎng)絡(luò)徹底斷了。但這里有個(gè)關(guān)鍵細(xì)節(jié)**主節(jié)點(diǎn)所在的機(jī)器本身沒有宕機(jī)Redis 進(jìn)程也沒有崩潰。**主節(jié)點(diǎn)依然可以接受客戶端連接和寫入只是它再也聯(lián)系不上從節(jié)點(diǎn)和哨兵了。此時(shí)其實(shí)已經(jīng)形成一個(gè)“網(wǎng)絡(luò)分區(qū)”分區(qū) A舊 master 連接它的客戶端。分區(qū) B哨兵 兩個(gè)從節(jié)點(diǎn) 通過哨兵路由的客戶端。4.2 第二階段哨兵判定主節(jié)點(diǎn)下線哨兵節(jié)點(diǎn)每隔sentinel monitor配置的時(shí)間間隔會(huì)向主節(jié)點(diǎn)發(fā)送 Ping。因?yàn)榫W(wǎng)絡(luò)斷了哨兵收不到主節(jié)點(diǎn)的 Pong 響應(yīng)等待超過down-after-milliseconds后哨兵會(huì)把這個(gè)主節(jié)點(diǎn)標(biāo)記為sdown主觀下線。如果 3 個(gè)哨兵都這樣認(rèn)為并且配置的quorum值小于等于 2那么主節(jié)點(diǎn)被標(biāo)記為odown客觀下線。于是哨兵開始執(zhí)行故障轉(zhuǎn)移流程。4.3 第三階段選出新主節(jié)點(diǎn)哨兵集群經(jīng)過投票選出一個(gè) Leader 哨兵由它執(zhí)行故障轉(zhuǎn)移從兩個(gè)從節(jié)點(diǎn)中選出一個(gè)執(zhí)行SLAVEOF NO ONE提升它為新的 master。另一個(gè)從節(jié)點(diǎn)執(zhí)行SLAVEOF new_master_ip new_master_port變成新主的從節(jié)點(diǎn)。哨兵更新自己的配置通知客戶端新的主節(jié)點(diǎn)地址。從這一刻開始分區(qū) B 中已經(jīng)有自己的 master 了。4.4 第四階段舊主依然接收寫入腦裂形成關(guān)鍵問題來了在分區(qū) A 中舊 master 依然活著依然接收客戶端的寫請(qǐng)求。如果客戶端沒有通過哨兵動(dòng)態(tài)感知主節(jié)點(diǎn)變更而是維護(hù)了一個(gè)靜態(tài)的主節(jié)點(diǎn)連接那么客戶端寫請(qǐng)求還是會(huì)打到舊 master 上。舊 master 接收到SET key value后它無法把這寫命令同步給從節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)斷了。但它會(huì)正常執(zhí)行并且告訴客戶端“寫入成功”。此時(shí)舊 master 上有最新的數(shù)據(jù)。新 master 上只有網(wǎng)絡(luò)斷開前同步過的老數(shù)據(jù)。兩個(gè)“主節(jié)點(diǎn)”同時(shí)接受寫請(qǐng)求數(shù)據(jù)開始分叉。這就是 Redis 腦裂的完成形態(tài)。4.5 第五階段網(wǎng)絡(luò)恢復(fù)和無情的數(shù)據(jù)丟失假設(shè)網(wǎng)絡(luò)修復(fù)了舊 master 和哨兵、從節(jié)點(diǎn)的連接恢復(fù)了。哨兵發(fā)現(xiàn)舊 master 還活著但此時(shí)新 master 已經(jīng)產(chǎn)生。那么哨兵會(huì)強(qiáng)制把舊 master 降級(jí)為從節(jié)點(diǎn)并向新 master 發(fā)起全量同步full resync。全量同步意味著什么意味著舊 master 會(huì)在同步前清空自己的數(shù)據(jù)然后加載新 master 的 RDB 快照。在腦裂期間舊 master 上多寫入的數(shù)據(jù)全部丟失。這個(gè)數(shù)據(jù)丟失不可恢復(fù)因?yàn)樗鼜膩頉]有同步到任何其他節(jié)點(diǎn)。所以你看整個(gè)鏈路下來沒有任何一個(gè)環(huán)節(jié)是“故意丟數(shù)據(jù)”的但最終數(shù)據(jù)就是丟了。這就是分布式系統(tǒng)的一致性和可用性博弈的代價(jià)。5. 如何判斷 Redis 是否發(fā)生過腦裂腦裂發(fā)生的時(shí)候業(yè)務(wù)端不一定有明顯報(bào)錯(cuò)數(shù)據(jù)丟失也常常是“悄悄發(fā)生”的。但我們可以通過一些跡象和命令來判斷。5.1 查看哨兵日志哨兵日志里會(huì)有明顯的故障轉(zhuǎn)移記錄。當(dāng)你發(fā)現(xiàn)以下日志時(shí)說明發(fā)生過主備切換# 主觀下線 sdown master mymaster 192.168.1.10 6379 # 客觀下線 odown master mymaster 192.168.1.10 6379 #quorum 2/2 # 開始故障轉(zhuǎn)移 try-failover master mymaster 192.168.1.10 6379 # 選出了新主 switch-master mymaster 192.168.1.10 6379 192.168.1.11 6379switch-master后面那行就是切換前后的主節(jié)點(diǎn)地址?？吹竭@一行就要意識(shí)到剛才可能發(fā)生過腦裂。5.2 檢查 Redis 節(jié)點(diǎn)的角色變化使用info replication命令可以查看當(dāng)前節(jié)點(diǎn)的角色信息。在舊主節(jié)點(diǎn)上執(zhí)行redis-cli -p 6379 info replication正常情況下主節(jié)點(diǎn)的role應(yīng)該是master。如果發(fā)生了腦裂且網(wǎng)絡(luò)已恢復(fù)舊主會(huì)被降級(jí)為slave并指向新主。如果腦裂尚未恢復(fù)你可以看到舊主還是master但它的connected_slaves計(jì)數(shù)為 0說明沒有從節(jié)點(diǎn)連接它這就很可疑。# 舊主節(jié)點(diǎn)在腦裂期間的輸出 role:master connected_slaves:0 master_replid:xxxxx再看新主節(jié)點(diǎn)能看到它已經(jīng)有從節(jié)點(diǎn)了# 新主節(jié)點(diǎn)恢復(fù)后的輸出 role:master connected_slaves:1 slave0:ip192.168.1.12,port6379,stateonline,offset12345,lag05.3 查看命令統(tǒng)計(jì)中的延遲和拒絕如果配置了min-replicas-to-write參數(shù)后面會(huì)講腦裂期間舊主會(huì)拒絕寫入。此時(shí)通過info stats命令可以看到redis-cli -p 6379 info stats | grep rejected sync_rejected_writes:5sync_rejected_writes統(tǒng)計(jì)了因?yàn)閺墓?jié)點(diǎn)數(shù)量不足而被拒絕的寫命令數(shù)量。一旦這個(gè)值大于 0說明系統(tǒng)曾經(jīng)觸發(fā)過寫保護(hù)。5.4 客戶端側(cè)如何發(fā)現(xiàn)如果你用的是 Lettuce 或 Jedis 客戶端并且配置了哨兵模式當(dāng)主節(jié)點(diǎn)變更時(shí)客戶端會(huì)收到重定向通知。但這里有個(gè)容易被忽略的坑舊主節(jié)點(diǎn)只是網(wǎng)絡(luò)分區(qū)并沒有真正宕機(jī)客戶端如果保持長(zhǎng)連接它不會(huì)主動(dòng)感知主節(jié)點(diǎn)變更。所以在實(shí)際項(xiàng)目中更可靠的做法是通過 Redis Sentinel 獲取當(dāng)前主節(jié)點(diǎn)地址來建立連接并監(jiān)聽主節(jié)點(diǎn)切換事件。這樣在主節(jié)點(diǎn)切換時(shí)客戶端能重新建立連接。具體的處理邏輯各語言客戶端支持不同落地時(shí)要選對(duì) API。6. 防止 Redis 腦裂后的數(shù)據(jù)丟失min-replicas 詳解明白了腦裂的原理現(xiàn)在要解決實(shí)際問題怎么防止腦裂時(shí)的數(shù)據(jù)丟失。有人可能會(huì)說那我不用主從、不用哨兵行不行當(dāng)然可以但這就放棄了高可用。如果你的業(yè)務(wù)允許短暫停機(jī)單節(jié)點(diǎn) Redis 反而是最簡(jiǎn)單可靠的方案。但大多數(shù)生產(chǎn)系統(tǒng)需要高可用所以必須接受“主備切換可能發(fā)生”這個(gè)現(xiàn)實(shí)。在此基礎(chǔ)上我們能做的是讓舊主在失去從節(jié)點(diǎn)同步能力時(shí)主動(dòng)拒絕寫入。這樣就算腦裂發(fā)生舊主上也不會(huì)產(chǎn)生新數(shù)據(jù)網(wǎng)絡(luò)恢復(fù)后降級(jí)為從節(jié)點(diǎn)數(shù)據(jù)不會(huì)丟。這個(gè)能力 Redis 早就提供了就是min-replicas-to-write和min-replicas-max-lag。6.1 配置項(xiàng)說明在 Redis 的配置文件中redis.conf主節(jié)點(diǎn)可以設(shè)置兩個(gè)參數(shù)# 當(dāng)主節(jié)點(diǎn)擁有的健康的從節(jié)點(diǎn)數(shù)量小于該值時(shí)停止接受寫請(qǐng)求 min-replicas-to-write 1 # 從節(jié)點(diǎn)的數(shù)據(jù)同步延遲超過該值秒視為不健康 min-replicas-max-lag 10含義是min-replicas-to-write 1主節(jié)點(diǎn)必須至少有一個(gè)健康的從節(jié)點(diǎn)才允許接受寫請(qǐng)求。min-replicas-max-lag 10從節(jié)點(diǎn)的復(fù)制延遲lag不能超過 10 秒。如果超過就認(rèn)為這個(gè)從節(jié)點(diǎn)不健康。兩個(gè)條件同時(shí)滿足才允許寫。也就是說如果健康的從節(jié)點(diǎn)數(shù)量 min-replicas-to-write拒絕寫入?；氐侥X裂場(chǎng)景網(wǎng)絡(luò)分區(qū)后舊主無法和從節(jié)點(diǎn)通信從節(jié)點(diǎn) lag 不斷增長(zhǎng)超過 10 秒。主節(jié)點(diǎn)檢查發(fā)現(xiàn)“健康從節(jié)點(diǎn)數(shù)量”變?yōu)?0小于配置的min-replicas-to-write 1。于是后續(xù)的寫請(qǐng)求被拒絕客戶端會(huì)報(bào)錯(cuò)不是寫入超時(shí)而是直接被拒。這樣舊主就不會(huì)產(chǎn)生新的增量數(shù)據(jù)。網(wǎng)絡(luò)恢復(fù)后舊主降級(jí)為從節(jié)點(diǎn)數(shù)據(jù)依然一致不會(huì)丟失。6.2 動(dòng)態(tài)配置如果你已經(jīng)部署了 Redis可以通過命令動(dòng)態(tài)調(diào)整參數(shù)不用重啟# 登錄 Redis 后執(zhí)行 CONFIG SET min-replicas-to-write 1 CONFIG SET min-replicas-max-lag 10 # 同時(shí)寫入配置文件防止重啟后失效 CONFIG REWRITE6.3 這兩個(gè)配置有什么代價(jià)先說清楚min-replicas-to-write不是沒有代價(jià)的。假設(shè)你的主節(jié)點(diǎn)確實(shí)掛了但是從節(jié)點(diǎn)還沒有被哨兵提升為新主這期間客戶端寫入會(huì)失敗。相當(dāng)于用“暫時(shí)不可用”換取了“數(shù)據(jù)不丟失”。這其實(shí)是把 Redis 從“可用性優(yōu)先”拉向了“一致性優(yōu)先”。對(duì)緩存場(chǎng)景來說寫入失敗問題不大緩存 miss 后下次再寫即可。但對(duì)分布式鎖、秒殺扣減庫存、訂單狀態(tài)更新等強(qiáng)一致場(chǎng)景寫入失敗比“寫入成功但數(shù)據(jù)丟失”要好得多因?yàn)榍罢咧辽倌鼙粯I(yè)務(wù)方感知并重試后者是無聲丟失排查代價(jià)極高。所以在生產(chǎn)環(huán)境建議這樣配置場(chǎng)景建議只做緩存允許少量數(shù)據(jù)丟失可以不配置 min-replicas-to-write 或設(shè) 0緩存 數(shù)據(jù)一致性要求高配置min-replicas-to-write 1分布式鎖 / 強(qiáng)一致業(yè)務(wù)必須配置且要配合 RedLock 等方案做兜底6.4 配置參考示例以下是一個(gè)完整的 redis.conf 主節(jié)點(diǎn)相關(guān)配置示例可作為生產(chǎn)環(huán)境模板參考# 基本主從配置 replica-read-only yes # 腦裂保護(hù) min-replicas-to-write 1 min-replicas-max-lag 107. 完整實(shí)踐搭建一個(gè)可復(fù)現(xiàn)腦裂的 Redis 環(huán)境理解了理論最好親手驗(yàn)證一次。下面用一個(gè)最小化的本地環(huán)境模擬“主節(jié)點(diǎn)網(wǎng)絡(luò)分區(qū)導(dǎo)致腦裂和數(shù)據(jù)丟失”的過程。7.1 環(huán)境準(zhǔn)備在本地安裝 Redis 后創(chuàng)建三個(gè)目錄分別模擬三個(gè)節(jié)點(diǎn)mkdir -p /tmp/redis-lab/{6379,6380,6381}分別創(chuàng)建三個(gè)配置文件。主節(jié)點(diǎn)配置 /tmp/redis-lab/6379/redis.confport 6379 daemonize yes dir /tmp/redis-lab/6379 logfile redis.log pidfile /tmp/redis-lab/6379/redis.pid # 腦裂保護(hù)配置 min-replicas-to-write 1 min-replicas-max-lag 10從節(jié)點(diǎn) 1 配置 /tmp/redis-lab/6380/redis.confport 6380 daemonize yes dir /tmp/redis-lab/6380 logfile redis.log pidfile /tmp/redis-lab/6380/redis.pid replicaof 127.0.0.1 6379從節(jié)點(diǎn) 2 配置 /tmp/redis-lab/6381/redis.confport 6381 daemonize yes dir /tmp/redis-lab/6381 logfile redis.log pidfile /tmp/redis-lab/6381/redis.pid replicaof 127.0.0.1 63797.2 啟動(dòng)節(jié)點(diǎn)redis-server /tmp/redis-lab/6379/redis.conf redis-server /tmp/redis-lab/6380/redis.conf redis-server /tmp/redis-lab/6381/redis.conf啟動(dòng)后在主節(jié)點(diǎn)上確認(rèn)從節(jié)點(diǎn)已經(jīng)連上redis-cli -p 6379 info replication預(yù)期輸出類似# Replication role:master connected_slaves:2 slave0:ip127.0.0.1,port6380,stateonline,offset14,lag0 slave1:ip127.0.0.1,port6381,stateonline,offset14,lag07.3 模擬網(wǎng)絡(luò)分區(qū)為了模擬腦裂我們不能直接殺掉主節(jié)點(diǎn)進(jìn)程因?yàn)?Redis 主節(jié)點(diǎn)如果真正宕機(jī)就不會(huì)再接受寫請(qǐng)求了。正確做法是使用 Linux 的iptables規(guī)則只阻斷主節(jié)點(diǎn)到從節(jié)點(diǎn)、哨兵的通信但保留主節(jié)點(diǎn)到客戶端的連接。在真實(shí)環(huán)境中網(wǎng)絡(luò)分區(qū)往往就是這么發(fā)生的。# 阻斷主節(jié)點(diǎn) 6379 訪問 6380 和 6381 的端口 iptables -A OUTPUT -p tcp --dport 6380 -j DROP iptables -A OUTPUT -p tcp --dport 6381 -j DROP7.4 觀察腦裂保護(hù)是否生效等 10 秒以上超過 min-replicas-max-lag 設(shè)定的 10 秒讓主節(jié)點(diǎn)察覺到從節(jié)點(diǎn)延遲超限。此時(shí)向主節(jié)點(diǎn)寫入數(shù)據(jù)redis-cli -p 6379 set name test-split-brain預(yù)期返回錯(cuò)誤(error) NOREPLICAS Not enough good replicas to write.這個(gè)錯(cuò)誤告訴我們主節(jié)點(diǎn)因?yàn)榻】祻墓?jié)點(diǎn)數(shù)量不足已經(jīng)拒絕寫入。7.5 模擬未配置保護(hù)的后果現(xiàn)在我們?nèi)サ裟X裂保護(hù)配置再來一次redis-cli -p 6379 CONFIG SET min-replicas-to-write 0 redis-cli -p 6379 CONFIG SET min-replicas-max-lag 0再執(zhí)行寫入redis-cli -p 6379 set name data-without-protection # 輸出 OK這時(shí)主節(jié)點(diǎn)會(huì)返回OK。如果你在真實(shí)生產(chǎn)環(huán)境不小心出現(xiàn)過這種情況說明腦裂期間數(shù)據(jù)已經(jīng)開始分叉了。7.6 清理環(huán)境實(shí)驗(yàn)結(jié)束后清除防火墻規(guī)則并停止 Redisiptables -F redis-cli -p 6379 shutdown nosave redis-cli -p 6380 shutdown nosave redis-cli -p 6381 shutdown nosave這里要額外提醒iptables -F會(huì)清空所有自定義規(guī)則如果在有業(yè)務(wù)流量的機(jī)器上執(zhí)行要謹(jǐn)慎。建議實(shí)驗(yàn)環(huán)境使用專用的 namespace 或測(cè)試機(jī)生產(chǎn)環(huán)境不要直接操作防火墻規(guī)則來模擬分區(qū)。這個(gè)實(shí)驗(yàn)的核心結(jié)論是不配置 min-replicas-to-write主節(jié)點(diǎn)會(huì)傻傻地持續(xù)接受寫入直到數(shù)據(jù)被覆蓋配置了之后主節(jié)點(diǎn)在失去從節(jié)點(diǎn)連接時(shí)會(huì)主動(dòng)“暫停寫入”寧可報(bào)錯(cuò)也不讓數(shù)據(jù)分裂。8. 生產(chǎn)環(huán)境 Redis 腦裂的常見問題與排查思路在實(shí)際生產(chǎn)環(huán)境腦裂的排查往往比模擬復(fù)雜得多。這里整理幾個(gè)高頻問題和對(duì)應(yīng)排查路徑。問題現(xiàn)象可能原因排查方式解決方案業(yè)務(wù)突然大批量報(bào) NOREPLICAS 錯(cuò)誤主節(jié)點(diǎn)健康從節(jié)點(diǎn)數(shù)量不足查看主節(jié)點(diǎn)info replication確認(rèn) connected_slaves 數(shù)量和 lag檢查從節(jié)點(diǎn)網(wǎng)絡(luò)、主從復(fù)制狀態(tài)根據(jù)業(yè)務(wù)容忍度調(diào)整 min-replicas 參數(shù)主節(jié)點(diǎn)日志出現(xiàn)switch-master但客戶端沒有感知客戶端沒有通過哨兵獲取主節(jié)點(diǎn)地址查看客戶端連接配置是否使用 Sentinel-aware 模式改用帶哨兵感知的客戶端 API訂閱主節(jié)點(diǎn)切換事件網(wǎng)絡(luò)恢復(fù)后舊主數(shù)據(jù)被清空哨兵將舊主降級(jí)為從節(jié)點(diǎn)并執(zhí)行全量同步檢查舊主info replication的 run_id 和數(shù)據(jù)量變化配置 min-replicas-to-write 從源頭避免舊主寫入腦裂期間寫請(qǐng)求超時(shí)而非報(bào)錯(cuò)舊主網(wǎng)絡(luò)隔離但 TCP 連接未斷開請(qǐng)求遲遲得不到響應(yīng)抓包確認(rèn)連接狀態(tài)查看應(yīng)用端超時(shí)配置在客戶端設(shè)置合理的超時(shí)時(shí)間配合 Redis 側(cè) min-replicas 快速拒絕哨兵判定主觀下線過于頻繁down-after-milliseconds設(shè)置過小主節(jié)點(diǎn)因負(fù)載高或 GC 停頓誤判查看哨兵日志中 sdown 的觸發(fā)時(shí)間和主節(jié)點(diǎn)負(fù)載調(diào)大 down-after-milliseconds降低誤判概率主節(jié)點(diǎn)切換后數(shù)據(jù)延遲很大從節(jié)點(diǎn)的復(fù)制積壓緩沖區(qū)設(shè)置過小導(dǎo)致切換后需要全量同步查看從節(jié)點(diǎn)日志中是否有 full resync調(diào)大 repl-backlog-size減少全量同步頻率8.1 排查思路的順序遇到疑似腦裂問題時(shí)建議按下面的順序排查先看哨兵日志確認(rèn)是否發(fā)生過主備切換。再對(duì)比主從節(jié)點(diǎn)的run_id查看歷史上是否有多個(gè) run_id 交替。然后檢查主從節(jié)點(diǎn)的info replication確認(rèn)當(dāng)前角色和數(shù)據(jù)同步狀態(tài)。最后通過slowlog和應(yīng)用日志定位數(shù)據(jù)丟失的時(shí)間窗口確認(rèn)是否與主備切換時(shí)間吻合。要注意的是Redis 本身沒有直接記錄“腦裂事件”的日志項(xiàng)需要結(jié)合哨兵日志、節(jié)點(diǎn)角色變化、客戶端錯(cuò)誤日志三份信息交叉驗(yàn)證。9. 最佳實(shí)踐與工程建議Redis 腦裂這個(gè)問題越早做防護(hù)成本越低。下面這套配置和方案是我認(rèn)為在實(shí)際項(xiàng)目里比較穩(wěn)妥的基線。9.1 配置層面至少做到這一步在所有的 master 節(jié)點(diǎn)上配置min-replicas-to-write 1 min-replicas-max-lag 10解釋一下為什么是 1 和 10min-replicas-to-write 1只要還有 1 個(gè)健康從節(jié)點(diǎn)主節(jié)點(diǎn)就繼續(xù)服務(wù)保證可用性當(dāng)從節(jié)點(diǎn)全部失聯(lián)時(shí)拒絕寫入保證一致性。min-replicas-max-lag 10允許從節(jié)點(diǎn)最多延遲 10 秒。10 秒是一個(gè)相對(duì)合理的閾值既能容忍網(wǎng)絡(luò)的瞬時(shí)抖動(dòng)又不會(huì)讓數(shù)據(jù)分歧窗口過大。如果你的業(yè)務(wù)對(duì)數(shù)據(jù)一致性要求極高比如用 Redis 存庫存、存訂單狀態(tài)可以進(jìn)一步收緊min-replicas-to-write 2 min-replicas-max-lag 5但要注意配置越高可用性越低。如果只有一個(gè)從節(jié)點(diǎn)還宕機(jī)了主節(jié)點(diǎn)就會(huì)拒絕所有寫入這是必須要接受的權(quán)衡。9.2 架構(gòu)層面避免單點(diǎn)Redis 至少要一主兩從且三個(gè)節(jié)點(diǎn)分布在不同的物理機(jī)器上最好是不同機(jī)架。Sentinel 至少部署 3 個(gè)實(shí)例quorum設(shè)為 2保證故障轉(zhuǎn)移需要多數(shù)派同意?？蛻舳吮仨毷褂蒙诒兄倪B接方式不要直連寫死的主節(jié)點(diǎn)地址。9.3 客戶端層面記住“收到成功不代表真的安全”Redis 主從復(fù)制是異步的主節(jié)點(diǎn)返回 OK 不代表數(shù)據(jù)已經(jīng)同步到從節(jié)點(diǎn)。這一點(diǎn)只要使用了主從模式就無法徹底消除。所以對(duì)于強(qiáng)一致業(yè)務(wù)比如分布式鎖、扣減庫存還要考慮引入 RedLock 這樣的多節(jié)點(diǎn)寫入方案或者把最終一致性交給數(shù)據(jù)庫Redis 只做加速層。9.4 監(jiān)控層面要能第一時(shí)間發(fā)現(xiàn)切換建議監(jiān)控以下指標(biāo)master_link_down_since_seconds主從連接斷開時(shí)長(zhǎng)。connected_slaves主節(jié)點(diǎn)的從節(jié)點(diǎn)數(shù)量。master_repl_offset與slave_repl_offset的差主從復(fù)制延遲。哨兵日志中switch-master的出現(xiàn)頻率。一旦發(fā)現(xiàn)主從切換就要查一下切換原因確認(rèn)是真實(shí)的節(jié)點(diǎn)故障、還是網(wǎng)絡(luò)抖動(dòng)誤判。不要讓腦裂成為“事后才知道”的事。9.5 上線前做一次故障演練很多團(tuán)隊(duì)直到線上出問題才第一次見識(shí)腦裂。建議在測(cè)試環(huán)境做一次完整的故障演練搭建主從 哨兵環(huán)境。用 iptables 模擬主節(jié)點(diǎn)網(wǎng)絡(luò)分區(qū)。觀察哨兵是否發(fā)生切換。觀察舊主節(jié)點(diǎn)是否拒絕寫入。確認(rèn)網(wǎng)絡(luò)恢復(fù)后數(shù)據(jù)是否一致。整個(gè)演練不會(huì)超過半天但能幫團(tuán)隊(duì)提前暴露很多配置上的問題。腦裂這種問題演練時(shí)發(fā)現(xiàn)成本很低線上出現(xiàn)再復(fù)盤可能就是事故報(bào)告了。10. 總結(jié)與后續(xù)學(xué)習(xí)方向Redis 腦裂不是 Redis 特有的缺陷而是分布式系統(tǒng)在 CAP 約束下必然面對(duì)的問題。這篇文章核心講了四件事第一腦裂的本質(zhì)是網(wǎng)絡(luò)分區(qū)下舊主節(jié)點(diǎn)還在接收寫入而哨兵已經(jīng)選出了新主節(jié)點(diǎn)形成兩個(gè)主節(jié)點(diǎn)同時(shí)工作的局面。第二腦裂導(dǎo)致的數(shù)據(jù)丟失發(fā)生在網(wǎng)絡(luò)恢復(fù)后舊主被強(qiáng)制降級(jí)為從節(jié)點(diǎn)并執(zhí)行全量同步此前的增量寫入被直接覆蓋。第三最有效的預(yù)防手段是配置min-replicas-to-write和min-replicas-max-lag讓舊主在失去健康從節(jié)點(diǎn)時(shí)拒絕寫入用短暫不可用換取數(shù)據(jù)不丟失。第四生產(chǎn)環(huán)境不能只靠 Redis 側(cè)配置還要在客戶端、監(jiān)控、故障演練三個(gè)層面做好配套才能真正把腦裂的影響降到可控范圍。如果你想把這塊繼續(xù)深入下面幾個(gè)方向值得花時(shí)間Redis Sentinel 的選主算法和配置細(xì)節(jié)理解 quorum 和 majority 的區(qū)別。Redis Cluster 模式下的網(wǎng)絡(luò)分區(qū)處理機(jī)制它和主從 哨兵模式各有取舍。分布式鎖場(chǎng)景下 RedLock 的原理和爭(zhēng)議理解它為什么能降低腦裂風(fēng)險(xiǎn)。Redis 復(fù)制緩沖區(qū)repl-backlog和全量同步、增量同步的底層機(jī)制。建議先在自己本機(jī)把上面那個(gè)最小實(shí)驗(yàn)跑一遍親手看到 NOREPLICAS 錯(cuò)誤和數(shù)據(jù)分叉是什么感覺再去看源代碼和英文文檔會(huì)順暢很多。分布式系統(tǒng)的很多坑看十遍文檔不如親手踩一次。