先給結(jié)論Redis 集群并不是“只要還有主節(jié)點活著就能用”。在默認配置下只要有一個槽位失去所有者整個集群就會直接進入CLUSTERDOWN狀態(tài)所有讀寫全部被拒絕——一個分片的主從全掛能拖垮整個集群。這不是玄學(xué)而是集群設(shè)計從一開始就寫死的“要么完整要么全掛”的一致性偏好。這篇文章結(jié)合我多年維護和救火 Redis Cluster 的實際經(jīng)驗把會讓集群整體不可用的場景一個個列出來每個場景配套對應(yīng)的日志、報錯特征和恢復(fù)辦法適合正在用或者準備上線 Redis 集群的同學(xué)收藏。1. 先搞清楚集群的“可用”是怎么定義的1.1 槽位、復(fù)制、投票三件事Redis Cluster 的高可用不是靠“哪個節(jié)點活著”來判斷的它依賴三個底層機制槽位hash slot整個集群有 16384 個槽位按 key 的 CRC16 哈希值映射每個主節(jié)點負責(zé)一段槽位區(qū)間。只要有一個槽位沒有被任何節(jié)點負責(zé)集群狀態(tài)就是不一致的。復(fù)制replication每個主節(jié)點可以有多個從節(jié)點從節(jié)點實時復(fù)制主節(jié)點數(shù)據(jù)在主節(jié)點掛掉后可以接管它負責(zé)的槽位。投票voting主節(jié)點之間通過 gossip 協(xié)議互相發(fā)心跳默認cluster-node-timeout是 15000ms。一個節(jié)點超過這個時間沒收到另一個節(jié)點的心跳會先把它標記為PFAIL主觀下線當(dāng)集群內(nèi)多數(shù)主節(jié)點都認為它是PFAIL才升級為FAIL客觀下線。從PFAIL到FAIL這個設(shè)計非常關(guān)鍵它保證了“判定死亡”不是單個節(jié)點拍腦袋而是需要集群多數(shù)節(jié)點共同確認從機制上防腦裂。當(dāng)某個主節(jié)點確認失敗后它的從節(jié)點會發(fā)起FAILOVER_AUTH_REQUEST其他主節(jié)點投票誰的數(shù)據(jù)偏移量最新誰接替。但這個選舉有個硬前提必須拿到多數(shù)主節(jié)點的投票。票湊不齊從節(jié)點就永遠升不了主。1.2 “整個集群不可用”其實分兩個層次很多人理解的不可用是“節(jié)點全掛了”但 Redis 集群最常見、也最坑的一種不可用是節(jié)點明明活著集群卻整體拒絕服務(wù)。此時你連一個熱 key 都讀不出來返回的全是(error) CLUSTERDOWN The cluster is down這就是cluster_state: fail的狀態(tài)。觸發(fā)它的條件有兩個存在沒有節(jié)點負責(zé)的“孤兒槽位”節(jié)點認為自己和集群多數(shù)節(jié)點已失聯(lián)無法形成有效決策。這里有個核心參數(shù)cluster-require-full-coverage默認是yes。它的含義就是只要有任何一個槽位失去歸屬集群直接進入 fail 狀態(tài)所有客戶端請求全部拒絕。等于說整個集群的可用性被最差的那個分片拽著走。明白了這層邏輯下面講的所有“集群整體不可用”場景都會歸根到這兩個機制上。2. 什么情況會讓集群全盤拒絕服務(wù)2.1 主節(jié)點失聯(lián)超過半數(shù)投票選不出新主這是最直觀的場景假設(shè)集群有 5 個主節(jié)點某次交換機故障導(dǎo)致 3 個主節(jié)點同時失聯(lián)。剩下的 2 個主節(jié)點無法湊齊“多數(shù)票”所有失聯(lián)主節(jié)點的從節(jié)點都發(fā)起不了有效的 failover。于是這 3 個主節(jié)點負責(zé)的槽位全部變成孤兒槽位默認配置下整個集群CLUSTERDOWN。這里容易有個誤解很多人以為“掛了 3 個主還剩 2 個主能服務(wù)”但實際上 Redis 集群的可用性不是按“剩余節(jié)點數(shù)”算的而是按“槽位覆蓋完整性”和“選舉多數(shù)”算的。主庫大面積死亡后沒有多數(shù)票從庫無法自動接管即使部分槽位還有從庫活著槽位依舊處于“沒有有效主節(jié)點”的狀態(tài)cluster-require-full-coverage yes下所有讀寫被一刀切。換句話說“主節(jié)點故障超過半數(shù)”不是唯一的觸發(fā)條件任何讓槽位失去主從覆蓋的場景都能觸發(fā)全局不可用。2.2 某一組槽位的主從全部掛掉槽變成“孤兒”這是生產(chǎn)環(huán)境最容易被低估的風(fēng)險。只要一次物理機宕機恰好把某個分片的主節(jié)點和它所有從節(jié)點一起帶走哪怕其他分片全部健康整個集群也會因這一個分片的孤兒槽位而進入 fail 狀態(tài)。我用實際案例說明之前有一個 3 主 3 從的集群為了省機器把其中一組主從放在了同一臺物理機上。某天那臺機器磁盤損壞主和從一起沒了。存活的兩個分片運行正常Redis 卻對全集群所有讀寫返回CLUSTERDOWN。業(yè)務(wù)方反饋“整個緩存突然全掛了”實際上只掛了一臺物理機。這就是require-full-coverage的殘酷性它把 16384 個槽位看成整體一個分片的完整性等于整個集群的完整性。少一個槽位等于全掛。2.3 網(wǎng)絡(luò)分區(qū)把集群切成兩半集群最怕的不是單點故障而是網(wǎng)絡(luò)分區(qū)尤其是把節(jié)點切成了“大小兩個區(qū)”。假設(shè) 6 主 6 從跨兩個機房部署骨干網(wǎng)抖動把兩個機房切斷了。A 機房有 4 個主節(jié)點B 機房有 2 個主節(jié)點A 機房側(cè)因為擁有多數(shù)節(jié)點可以正常形成決策B 機房的主節(jié)點會被 majority 標記為 FAILA 機房內(nèi)的從庫可以發(fā)起接管B 機房側(cè)只有 2 個主節(jié)點永遠湊不齊 3 票無法進行任何選舉幾個主節(jié)點一旦需要 failover對應(yīng)的槽位就迅速變成孤兒槽位。結(jié)果往往是A 機房正常服務(wù)B 機房因為 sees 多數(shù)不可達加上孤兒槽位直接進入 fail 狀態(tài)。如果客戶端路由策略不當(dāng)業(yè)務(wù)請求在 B 機房一側(cè)全部報CLUSTERDOWN表現(xiàn)為“整個集群不可用”。這個場景沒有完美的解藥。Redis 集群的多數(shù)派機制決定了一件事它寧可讓一部分節(jié)點不可用也不允許腦裂后兩邊同時產(chǎn)生新主寫入數(shù)據(jù)。對很多團隊而言“分區(qū)期間一邊掛掉”是可以接受的真正不能接受的是兩邊同時寫、數(shù)據(jù)分叉。2.4 級聯(lián)失敗才是最常見的“整集群事故”真正導(dǎo)致 Redis 集群整體癱瘓的往往不是一次“精準打擊”而是級聯(lián)失敗。最典型的是下面這條鏈某主節(jié)點發(fā)生長耗時 GC 停頓或磁盤 IO 抖動心跳超過cluster-node-timeout其他節(jié)點把它標記為 PFAIL隨后多數(shù)確認 FAIL多個從節(jié)點同時對它發(fā)起 failover其中一個升主新主節(jié)點負載飆升同時觸發(fā)持久化和復(fù)制積壓又出現(xiàn)心跳超時新一輪 FAIL 繼續(xù)擴散多個分片進入 failover 循環(huán)。我在一次事故里看到過cluster-node-timeout被人從默認的 15000 調(diào)到了 3000理由是“加快故障切換”。結(jié)果一次全集群 GC 停頓 4 秒所有節(jié)點互相標記為 PFAIL一堆從庫同時嘗試 failover集群在十幾秒內(nèi)徹底 fail。把超時調(diào)得太小等于把誤判成本放到最大。2.5 配置型事故timeout 太小、bind 錯、時鐘漂移除了真實的故障還有一類“人禍”也會讓整個集群不可用而且這類問題排查起來特別費勁cluster-node-timeout設(shè)置過小任何一次突發(fā)延遲都可能引發(fā)全集群誤判多個分片同時 failovercluster-announce-ip/ bind 配置錯誤在容器或虛擬機環(huán)境里節(jié)點間通過錯誤的 IP 互相發(fā)現(xiàn)心跳斷斷續(xù)續(xù)集群長時間處于 PFAIL/FAIL 邊緣狀態(tài)極其不穩(wěn)定服務(wù)器時鐘漂移Redis 集群雖然不強制要求 NTP但時鐘不同步會直接影響心跳超時判斷和選舉紀元A 節(jié)點認為 B 已經(jīng)超時B 卻認為自己一切正常vote 混亂誤刪nodes.conf這個文件記錄了節(jié)點 ID 和集群拓撲重啟時如果文件被誤刪節(jié)點會以為自己是個新節(jié)點拿不到原來的槽位信息集群關(guān)系直接錯亂。配置型事故里nodes.conf被誤刪是我見過最容易造成“全網(wǎng)癱瘓”的操作直接導(dǎo)致槽位歸屬信息丟失集群無論如何都無法恢復(fù)只能重建或從備份恢復(fù)。3. 日常最容易踩的坑和配置取舍3.1 require-full-coverage一個參數(shù)決定全局生死這個參數(shù)是“整個集群不可用”話題里繞不開的開關(guān)必須單獨說。yes默認任何槽位裸奔全集群拒絕服務(wù)no槽位裸奔時訪問到裸奔槽位的請求報CLUSTERDOWN其他槽位照常服務(wù)。很多團隊會把no當(dāng)作保命配置我理解這個選擇但也想提醒它的問題設(shè)為no之后你必須要接受“部分請求報錯”這個常態(tài)。如果監(jiān)控只盯“集群節(jié)點存活”不盯“具體哪些槽不可用”很容易出現(xiàn)大量請求失敗卻沒人發(fā)現(xiàn)的情況。我的建議是線上核心鏈路能承受短時全停的保持默認yes配合完善的告警不能承受全停、寧可部分降級的設(shè)no但必須對cluster_state:fail和具體孤兒槽位做告警無論哪種都應(yīng)該在架構(gòu)上保證“每個分片的主從不在同一臺物理機/同一個可用區(qū)”否則require-full-coverage怎么配都救不了。提示cluster-require-full-coverage是 rolling 配置修改后逐節(jié)點生效但要在所有節(jié)點上保持一致否則節(jié)點間互相判定集群狀態(tài)不一致。3.2 持久化 fork 阻塞觸發(fā)“心跳失聯(lián)”Redis 執(zhí)行BGSAVE或 AOF rewrite 時要 fork 子進程。如果實例內(nèi)存很大fork 瞬間會阻塞主進程可能長達幾秒甚至十幾秒。所有節(jié)點同時在做定時持久化的話很可能集體錯過心跳窗口互相標記 PFAIL/FAIL。之前有個客戶集群內(nèi)存 80GB 實例把save配置設(shè)成了每 5 分鐘執(zhí)行一次結(jié)果高負載時段 fork 阻塞 8~10 秒恰好大于cluster-node-timeout整集群進入 failover 風(fēng)暴。應(yīng)對辦法很簡單把cluster-node-timeout調(diào)到 15~30 秒之間給 GC 和 fork 留出緩沖錯峰持久化別讓所有節(jié)點同一時刻 BGSAVE監(jiān)控 fork 耗時和redis-cli info stats里的latest_fork_usec超過閾值就要排查內(nèi)存和內(nèi)存碎片化問題。3.3 遷移/縮容中途宕機做 resharding 或者縮容時如果中途有節(jié)點宕機事情會非常難看。槽位遷移依賴MIGRATE命令數(shù)據(jù)遷移到一半時源節(jié)點和目標節(jié)點處于“migrating/importing”的中間狀態(tài)。這個狀態(tài)下如果源主節(jié)點掛了而它的從節(jié)點沒有同步到最新的遷移狀態(tài)槽位可能處于一種“既有人認領(lǐng)又沒人真正負責(zé)”的模糊狀態(tài)。這種情況最容易踩的坑是不看 cluster info 就開始操作集群變更。我的習(xí)慣是操作前先跑一遍redis-cli --cluster check確認cluster_slots_ok 16384且沒有 PFAIL/FAIL 節(jié)點再動拓撲。變更過程中嚴格避免同時進行另一項故障操作。3.4 熱 key 把單點打滿引發(fā)的連鎖Redis 集群沒有全局負載均衡key 落在哪個分片是哈希決定的。某個熱 key 所在的分片被打滿 CPU 或內(nèi)存后這個節(jié)點的響應(yīng)變慢心跳開始超時被標記為 FAIL從庫接管后繼續(xù)被打滿再次超時……這種“熱 key 導(dǎo)致單點故障單點故障觸發(fā)全局 fail”的鏈路本質(zhì)上和 2.4 的級聯(lián)失敗是同一種模式。唯一的解法是在業(yè)務(wù)層做熱點 key 拆分或者在架構(gòu)上把熱點 key 的訪問分散到多個 key 上減少單分片壓力。集群本身的故障轉(zhuǎn)移機制救不了“被打滿”的節(jié)點因為打滿它的流量還在。4. 哨兵方案和集群方案的邊界4.1 哨兵模式什么時候全掛很多團隊沒上 Cluster用的是主從加哨兵。哨兵模式下整集群不可用的觸發(fā)條件和 Cluster 不太一樣哨兵多數(shù)派消失假設(shè)部署 3 個哨兵任何一個哨兵宕機都不影響但如果 2 個哨兵同時宕機剩下 1 個哨兵即使發(fā)現(xiàn)主庫掛了也無法完成 failover需要多數(shù)派確認和選舉 leader。此時主庫宕機寫入直接中斷服務(wù)不可用。down-after-milliseconds設(shè)得太短哨兵對主庫的誤判也會導(dǎo)致頻繁 failover甚至主庫還在等服務(wù)卻已經(jīng)切換走寫入全部被拒。從庫被誤刪或者復(fù)制斷裂哨兵能發(fā)現(xiàn)主庫掛掉但從庫數(shù)據(jù)延遲過大failover 后接手的從庫缺少大量數(shù)據(jù)業(yè)務(wù)讀取到的是很久以前的數(shù)據(jù)這種“偽可用”比不可用更可怕。哨兵方案的核心保護參數(shù)是min-replicas-to-write舊版本叫min-slaves-to-write。設(shè)置為主庫至少有 N 個健康從庫時才接受寫入可以在極端情況下保護數(shù)據(jù)一致性代價是可用性下降。生產(chǎn)上到底設(shè)多少本質(zhì)上是業(yè)務(wù)寫多還是讀多、能容忍丟失多少數(shù)據(jù)。4.2 兩種方案“不可用”的條件對比我整理了一張對比表方便你直接根據(jù)自身架構(gòu)判斷風(fēng)險場景Redis Cluster哨兵 主從單主節(jié)點宕機從庫自動接管槽位仍覆蓋哨兵多數(shù)派存活時自動切換某一分片主從全掛槽位失控默認全集群 CLUSTERDOWN該主從鏈路不可用其他鏈路不受影響超過半數(shù)管理節(jié)點故障無法選舉槽位多個失控全局失敗哨兵無法構(gòu)成多數(shù)無法切換寫入中斷網(wǎng)絡(luò)分區(qū)多數(shù)派一側(cè)可繼續(xù)少數(shù)派一側(cè) fail哨兵分區(qū)主庫可能長期不切換或雙主風(fēng)險腦裂保護選舉投票機制天然防腦裂靠 quorum min-replicas 約束風(fēng)險更高一句話總結(jié)Cluster 用“全局槽位完整性”換來了強一致和高分片能力但也因此把單分片故障的影響面放大到全局哨兵方案各主從鏈路相對獨立反而沒那么容易被“一粒老鼠屎”拖垮整個集群。這也是為什么很多中小團隊到現(xiàn)在還堅持用哨兵而不是 Cluster。5. 出事后怎么定位和恢復(fù)5.1 三行命令先看現(xiàn)場集群進入未知狀態(tài)時第一件事千萬別重啟節(jié)點先做現(xiàn)場采集。我救火的一貫順序是redis-cli -h ip -p port cluster info redis-cli -h ip -p port cluster nodes redis-cli -h ip -p port cluster slotscluster info里的關(guān)鍵指標cluster_stateok還是failcluster_slots_assigned/cluster_slots_ok兩者不等說明有孤兒槽位cluster_known_nodes確認節(jié)點總數(shù)是否和預(yù)期一致。cluster nodes輸出里每一行代表一個節(jié)點重點看中間 flags 列myself當(dāng)前節(jié)點自己master/slave角色fail?PFAIL代表某個節(jié)點認為它有主觀故障嫌疑failFAIL已經(jīng)多數(shù)確認客觀下線disconnected該節(jié)點無法和集群內(nèi)其他節(jié)點正常通信。這三個命令能快速回答兩個問題集群是怎么掛的孤兒槽位還是多數(shù)派失聯(lián)以及哪些節(jié)點處于什么狀態(tài)。5.2 恢復(fù)順序和止血操作確認了故障類型后按下面的順序處理先救孤兒槽位。優(yōu)先啟動宕機的主節(jié)點或從節(jié)點讓槽位恢復(fù)歸屬。節(jié)點啟動后會自動根據(jù)nodes.conf里的拓撲信息重新加入集群不需要手動CLUSTER MEET。湊不齊多數(shù)時用 FORCE 接管。如果超過半數(shù)主節(jié)點失聯(lián)導(dǎo)致無法自動選舉可以在存活的從節(jié)點上執(zhí)行redis-cli -h replica-ip -p replica-port cluster failover forceFORCE可以繞過多數(shù)票機制讓從庫直接接管。注意這屬于緊急操作只有在你確認原主節(jié)點短期無法回來時才建議用否則會出現(xiàn)雙主風(fēng)險。節(jié)點恢復(fù)但數(shù)據(jù)不對時不要直接上線。原主節(jié)點重新啟動后它可能會帶著一份“舊數(shù)據(jù)”回到集群。cluster-replica-validity-factor默認值是 10意思是主節(jié)點失聯(lián)超過 10 個cluster-node-timeout后從庫不再自動讓它變回主節(jié)點避免陳舊數(shù)據(jù)污染集群。如果非要恢復(fù)優(yōu)先把它作為從庫掛回集群讓它先同步新主數(shù)據(jù)再切換角色。配置層面止血。緊急情況下可以先把cluster-require-full-coverage臨時改為no讓集群恢復(fù)部分可用把大面積故障的影響面收縮到受害分片。但這個操作只能救“孤兒槽位”場景救不了“選舉多數(shù)派丟失”場景。注意cluster failover force是高危操作。執(zhí)行前必須確認要接管的從庫具備最新的復(fù)制偏移量否則你恢復(fù)的是一個數(shù)據(jù)嚴重落后的“假主節(jié)點”。5.3 集群可用性排障速查下面這張表是我自己壓箱底的排障速查遇到問題直接對照報錯信息典型場景恢復(fù)方向CLUSTERDOWN The cluster is down存在孤兒槽位或多數(shù)派失聯(lián)啟動死節(jié)點、檢查槽位覆蓋、必要時 force failoverCLUSTERDOWN Hash slot not served某個槽位無主可依多半是 require-full-coverage no 狀態(tài)下的局部不可用恢復(fù)該分片主從MOVED slot ip:port客戶端用了舊路由信息使用支持自動路由的客戶端或刷新集群拓撲ASK slot ip:port槽位正在遷移的中間狀態(tài)客戶端處理 ASK-REDIRECT或等待遷移完成MASTERDOWN Link with MASTER is down哨兵模式下主庫掛掉且從庫拒絕舊數(shù)據(jù)讀取觸發(fā)或手動執(zhí)行哨兵 failoverLOADING Redis is loading the dataset節(jié)點重啟加載 RDB/AOF 中等待加載完成檢查持久化文件是否過大OOM command not allowed when used memory節(jié)點達到 maxmemory寫入被拒擴容、清理 key、調(diào)整淘汰策略5.4 關(guān)于告警和演練的小建議還有一個值得單獨拿出來的經(jīng)驗集群不可用的恢復(fù)不一定靠“對”的操作更多時候靠“快”的響應(yīng)。如果你沒有提前做故障演練等到線上真的出現(xiàn)CLUSTERDOWN再去看日志、查節(jié)點狀態(tài)業(yè)務(wù)早就超時到爆炸了。我們團隊內(nèi)部會定期做三類演練隨機殺主節(jié)點驗證從庫能否在預(yù)期時間內(nèi)接管模擬網(wǎng)絡(luò)分區(qū)觀察兩端分區(qū)的 failover 行為是否符合預(yù)期演練過程中把cluster-node-timeout、require-full-coverage等關(guān)鍵參數(shù)逐個調(diào)整驗證監(jiān)控告警是否真的能觸發(fā)。不做演練的集群配置再漂亮也只是紙面高可用。6. 最后說點運維層面的體會這幾年的經(jīng)驗里我最深的感受是Redis 集群的整體不可用幾乎都不是“設(shè)計缺陷”而是“配置和部署方式?jīng)]跟上它的預(yù)期”。它默認認為每個分片的主從物理隔離、心跳網(wǎng)絡(luò)干凈、節(jié)點時鐘一致、節(jié)點數(shù)不會頻繁變動。你在哪個環(huán)節(jié)破了它它就在哪個環(huán)節(jié)拉爆全局。cluster-node-timeout別調(diào)到 5 秒以下require-full-coverage別在沒搞清數(shù)據(jù)一致性代價時隨意改節(jié)點變更前記得先看cluster info跨機房部署一定要確認多數(shù)派在一個區(qū)內(nèi)。這些都不是新知識但每一條都是從真實的線上事故里摔出來的。如果你現(xiàn)在正在規(guī)劃集群方案我的建議是先把“容忍哪部分不可用”想清楚再決定用什么方案、調(diào)什么參數(shù)。高可用從來沒有銀彈只有你愿意為哪一種故障買單的選擇。