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