兄弟們在做分布式系統(tǒng)的時候一定遇到過這種場景單機數(shù)據(jù)庫里的本地事務跑得挺順結(jié)果一拆成微服務、一上分布式數(shù)據(jù)庫數(shù)據(jù)就各種對不上。訂單狀態(tài)改了庫存卻扣重了用戶支付成功了積分系統(tǒng)卻查不到記錄。這些問題歸根結(jié)底就倆字一致性。而一致性背后是分布式事務模型和一致性算法在撐著。今天這篇不是教科書復讀我盡量用干活的視角把CAP、分布式事務模型、還有Raft這套東西捋清楚講明白它們到底怎么落到工程里踩過哪些坑選型的時候該怎么權(quán)衡。這篇內(nèi)容適合真正在做微服務拆分、分布式數(shù)據(jù)庫選型、或者自己動手寫共識模塊的工程師。不需要你數(shù)學多好但最好對分布式系統(tǒng)的基本概念有點體感。我會把整個鏈路拆成四塊來講先回到問題源頭看一致性的本質(zhì)再展開CAP這個不可能三角然后擼一遍分布式事務的主流模型和選型依據(jù)最后把從Paxos到Raft的演進邏輯以及Raft的核心機制逐層扒開。全程有類比、有場景、有參數(shù)、有對比盡量讓你看完能直接拿來用。1. 分布式系統(tǒng)的一致性問題根源1.1 從單機事務到分布式事務問題是怎么產(chǎn)生的單機數(shù)據(jù)庫里ACID事務是數(shù)據(jù)庫自己通過鎖、日志、回滾段來保證的。你執(zhí)行一條UPDATE要么成功要么失敗中間狀態(tài)外部不可見異常了還能回滾。這套機制在單機上是天經(jīng)地義的因為所有數(shù)據(jù)和操作都在同一個進程、同一塊磁盤上數(shù)據(jù)庫自己就能把控全局。但分布式系統(tǒng)不一樣。你的服務拆成了多個節(jié)點數(shù)據(jù)分散到多臺機器甚至分布在多個數(shù)據(jù)中心。這時候要完成一個跨節(jié)點的業(yè)務操作比如創(chuàng)建訂單扣庫存加積分這個操作涉及三個不同的服務每個服務又各自連著自己的數(shù)據(jù)庫。如果按照單機思路每個服務干自己的事、提交自己的事務問題馬上就來了訂單建好了庫存扣減失敗了或者積分服務超時了這時怎么辦最直接的辦法就是讓這三個操作保持同生共死要么全成功要么全回滾。這就是分布式事務要解決的問題。跟單機事務最大的不同在于單機事務有統(tǒng)一的協(xié)調(diào)者數(shù)據(jù)庫自身有全局可見的鎖狀態(tài)有可靠的本地日志而分布式系統(tǒng)里協(xié)調(diào)者需要自己設計節(jié)點間的通信是不可靠的網(wǎng)絡可能延遲、亂序、斷連節(jié)點可能宕機根本不存在一個上帝視角能一眼看清全局狀態(tài)。所以分布式事務的核心難點不是怎么做操作而是怎么讓多個節(jié)點達成共識并且容忍各種故障。1.2 分布式環(huán)境下的新挑戰(zhàn)網(wǎng)絡分區(qū)與節(jié)點故障分布式系統(tǒng)里兩個最棘手的問題一個是節(jié)點故障宕機、進程崩潰一個是網(wǎng)絡分區(qū)網(wǎng)絡不通、消息丟失、消息延遲。這兩種故障還不是互斥的經(jīng)常疊加出現(xiàn)。網(wǎng)絡分區(qū)特別惡心人的一點在于它讓判斷一個節(jié)點是否真的死了變得非常困難。假設你的訂單服務向庫存服務發(fā)送一條扣減請求超時了。這個超時代表什么可能是庫存服務真的掛了可能是網(wǎng)絡斷了幾秒鐘可能是消息在隊列里堵了也可能是庫存服務處理完但響應丟了。你根本沒法區(qū)分。在這個不確定面前任何全局一致的企圖都會受挫。所以在分布式事務和一致性算法的設計里你到處都能看到對故障的明確假設。CAP定理把所有可能的系統(tǒng)分成了三類就是對這種不確定性最經(jīng)典的抽象表達。理解了這個前提后面再看兩階段提交的協(xié)調(diào)者超時處理、看Raft的領導者選舉、看各種一致性模型的取舍你就知道每一項設計都是在跟不可靠網(wǎng)絡做斗爭。2. CAP定理深度拆解分布式系統(tǒng)的不可能三角2.1 CAP三個字母到底在說什么CAP是Consistency一致性、Availability可用性、Partition Tolerance分區(qū)容錯性的縮寫。這套理論最早是Eric Brewer在2000年提出的后來由Gilbert和Lynch給出了形式化證明簡單說就是在網(wǎng)絡分區(qū)發(fā)生時一個分布式系統(tǒng)無法同時保證強一致性和高可用性只能在兩者之間做取舍。先把三個概念摳清楚不然很多討論都是在雞同鴨講。一致性Consistency在這里指的是線性一致性Linearizability也就是強一致性?？蛻舳俗x取數(shù)據(jù)時如果某個寫操作已經(jīng)成功返回那么后續(xù)任何讀操作都必須讀到這個新值并且所有節(jié)點對數(shù)據(jù)的讀取順序在全球范圍內(nèi)完全一致。你可以把它理解為整個系統(tǒng)就像只有一份數(shù)據(jù)、一個操作順序所有并發(fā)操作被串行化了?？捎眯訟vailability指的是每次請求都能在有限時間內(nèi)得到回應。這里不要求回應的內(nèi)容一定是最新的但必須是一個合法的結(jié)果成功或失敗都行不能無限掛起。換句話說系統(tǒng)不能因為某個節(jié)點故障或網(wǎng)絡問題就拒絕服務。分區(qū)容錯性Partition Tolerance指的是系統(tǒng)在網(wǎng)絡分區(qū)節(jié)點間消息丟失或延遲無限大的情況下仍能繼續(xù)運行。注意P不是一種選擇而是分布式系統(tǒng)的必然屬性——只要你的系統(tǒng)部署在網(wǎng)絡上分區(qū)就是不可避免的。所謂三選二其實是個偽命題正確的理解是在分區(qū)發(fā)生時C和A只能保留一個。2.2 為什么最多只能滿足兩個用一個特別經(jīng)典的例子來解釋。假設有兩個副本節(jié)點N1和N2初始值都是X0?，F(xiàn)在客戶端向N1發(fā)起一個寫請求把X改成1并且N1成功執(zhí)行了這個寫操作。但緊接著N1和N2之間的網(wǎng)絡斷開了分區(qū)發(fā)生。這時客戶端向N2發(fā)起讀請求問題來了如果N2返回X0那就沒有滿足一致性因為客戶端剛寫入的值是1但讀到的卻是舊值。如果為了滿足一致性N2必須停下來等待與N1同步等待期間無法響應——那就沒有滿足可用性。你看在分區(qū)這個前提下C和A出現(xiàn)了不可調(diào)和的沖突。那如果不發(fā)生分區(qū)呢當然可以同時滿足C和A但那只是單機或無故障的特例沒有討論意義。在真實生產(chǎn)環(huán)境中分區(qū)是常態(tài)所以每個分布式系統(tǒng)實際都在做選擇題要CP還是AP。2.3 CP與AP的工程取舍實際系統(tǒng)怎么選選CP還是AP沒有絕對的對錯完全看業(yè)務場景。CP系統(tǒng)在分區(qū)發(fā)生時選擇暫停服務拒絕寫入、拒絕讀取或部分拒絕以換取數(shù)據(jù)絕對的強一致。典型代表是ZooKeeper、etcd、HBase、Google Spanner。適用場景是那些數(shù)據(jù)錯了比暫時不可用更可怕的業(yè)務比如金融交易、分布式鎖、配置中心、元數(shù)據(jù)存儲。舉個例子分布式鎖如果出現(xiàn)兩個節(jié)點同時拿到鎖那可能引發(fā)嚴重的資源競爭或數(shù)據(jù)損壞所以鎖服務寧可短暫不可用也不能給客戶端分發(fā)出錯的結(jié)果。AP系統(tǒng)在分區(qū)發(fā)生時選擇繼續(xù)服務允許各分區(qū)臨時出現(xiàn)數(shù)據(jù)不一致但通過異步補償機制在分區(qū)恢復后逐步收斂到一致狀態(tài)。典型代表是Cassandra、DynamoDB、CouchDB以及大量微服務架構(gòu)中的業(yè)務系統(tǒng)。適用場景是那些短暫讀到舊數(shù)據(jù)可以接受但必須一直能用的業(yè)務比如商品列表、用戶會話、社交動態(tài)、購物車。電商大促時你看到商品庫存多顯示了幾件這個可以忍但如果你因為庫存服務不可用導致連商品詳情都刷不出來那損失就大了去了。我在實際項目里的感受是大部分業(yè)務系統(tǒng)的核心矛盾不是強一致而是高可用。真正需要強一致的地方往往是元數(shù)據(jù)層、配置層和資金流轉(zhuǎn)的核心環(huán)節(jié)其他業(yè)務全部走最終一致就夠用了。這也是為什么微服務架構(gòu)落地時分布式事務越往業(yè)務側(cè)越軟用最終一致性的方案越來越多。3. 分布式事務模型的分類與選型前面講了理論這一節(jié)來點實際能用的東西。分布式事務模型目前主流的有這么幾類2PC兩階段提交、3PC三階段提交、TCCTry-Confirm-Cancel、Saga長事務、本地消息表事務消息。它們對一致性的保障強度不同實現(xiàn)復雜度也天差地別。3.1 強一致路線2PC兩階段提交2PC是最經(jīng)典的分布式事務協(xié)議也最能體現(xiàn)強一致的思路。它引入一個協(xié)調(diào)者Coordinator節(jié)點把整個事務分成兩個階段階段一準備階段協(xié)調(diào)者向所有參與者比如訂單庫、庫存庫、積分庫發(fā)送準備提交的請求各參與者執(zhí)行本地事務到可提交狀態(tài)但不提交把事務寫入本地日志然后向協(xié)調(diào)者回復就緒或失敗。階段二提交階段協(xié)調(diào)者收集所有參與者的回復。如果全部就緒就廣播提交命令各參與者正式提交本地事務如果任一參與者回復失敗或超時未響應協(xié)調(diào)者就廣播回滾命令各參與者撤銷本地操作。這個方案聽起來邏輯清晰但工程實現(xiàn)里全是坑。最大的問題是同步阻塞所有參與者在準備好之后持有資源鎖直到第二階段結(jié)束才能釋放。如果協(xié)調(diào)者宕機所有參與者都要一直阻塞著整個系統(tǒng)就卡住了。另外協(xié)調(diào)者是單點它掛了整個事務就沒法推進極端情況下甚至會出現(xiàn)各參與者狀態(tài)不一致協(xié)調(diào)者廣播提交時崩潰一部分節(jié)點收到消息提交了另一部分沒收到就回滾了。所以純2PC在分布式數(shù)據(jù)庫內(nèi)部用得比較多比如TiDB的PD調(diào)度、MySQL XA因為數(shù)據(jù)庫可以在內(nèi)部通過超時、重試和節(jié)點恢復機制來兜底。但在微服務架構(gòu)中跨服務調(diào)用鏈上直接裸用2PC非常痛苦——網(wǎng)絡超時、服務重試、事務狀態(tài)丟失都是麻煩這也是后來TCC和Saga被大量應用的原因。3.2 最終一致路線TCC、Saga、本地消息表TCC的思想是把一個業(yè)務操作拆成三個動作Try資源檢查和鎖定、Confirm確認執(zhí)行、Cancel取消回滾。它比2PC更貼合業(yè)務因為Try階段做的不是數(shù)據(jù)的物理變更而是預留資源。比如扣庫存Try階段只是凍結(jié)庫存數(shù)量Confirm階段才真正扣減Cancel階段解凍。TCC解決了2PC的同步阻塞問題——Try階段完成就可以釋放資源鎖Confirm和Cancel都是異步補償。但TCC對業(yè)務代碼侵入非常強每個操作都得寫三套邏輯而且Confirm和Cancel要做到冪等否則重復調(diào)用會產(chǎn)生臟數(shù)據(jù)。這里我說一個TCC落地最常見的坑Confirm和Cancel的觸發(fā)順序在某些異常場景下不可控。比如協(xié)調(diào)者在發(fā)送Confirm前宕機恢復后重發(fā)但業(yè)務方因為之前已經(jīng)執(zhí)行過Confirm且網(wǎng)絡丟了響應重復執(zhí)行就不能報錯必須能識別這已提交過。Saga則是把一個長事務拆成一系列本地事務每個本地事務完成后都發(fā)布一個事件由后續(xù)的本地事務響應事件繼續(xù)推進。如果某個步驟失敗Saga會反向執(zhí)行補償事務把之前的操作逐步回滾。Saga的典型實現(xiàn)方式是Choreography編排式和Orchestration編排中心式。前者靠事件驅(qū)動各服務自己訂閱發(fā)布適合流程簡單的情況后者有一個中心化的Saga執(zhí)行器來串聯(lián)整個事務流程復雜性可控適合業(yè)務邏輯較長的場景。本地消息表事務消息的思路也很實用把某個核心操作和發(fā)消息放在同一個本地事務里。比如訂單服務在創(chuàng)建訂單的同時往本地消息表插入一條扣減庫存的事情記錄提交事務后再異步發(fā)送消息到MQ。消息隊列確保至少投遞成功下游消費成功后再回調(diào)確認。如果本地事務提交了但消息發(fā)送失敗后臺任務會定時掃描消息表把未確認的消息重新投遞。這個方案最大的優(yōu)勢是簡單、不侵入業(yè)務落地成本低而且各服務解耦。3.3 事務模型選型對比為了讓你選型時有概念我直接整理了一張對比表方案一致性強度性能開銷實現(xiàn)復雜度業(yè)務侵入適用場景2PC強一致高鎖持續(xù)時間長中低數(shù)據(jù)庫內(nèi)部事務、小規(guī)?？鐜觳僮鱐CC最終一致Confirm階段業(yè)務保證中高高資金、庫存等核心資源操作需精細控制資源狀態(tài)Saga最終一致中低中中長流程業(yè)務如訂單創(chuàng)建支付出庫允許中間狀態(tài)本地消息表/事務消息最終一致低低低消息驅(qū)動的異步流程跨服務解耦注意事務模型的選擇不能脫離業(yè)務單獨談。我在實際項目里一般先畫一張事務邊界圖把每個核心操作的數(shù)據(jù)寫入路徑梳理出來判斷每個路徑對一致性的真實容忍度再決定哪一段用TCC、哪一段走Saga、哪一段只靠MQ解耦。不存在銀彈只有適不適合當前場景。4. 一致性算法的演進從Paxos到Raft搞清楚了分布式事務再看一致性算法就順了。因為分布式事務的強一致方案比如2PC本質(zhì)上需要一個讓多個節(jié)點對某個決策達成一致的機制而真正健壯、能容錯的共識算法一直到Paxos才算是有了突破。4.1 Paxos為什么難懂又難實現(xiàn)Paxos是Leslie Lamport在1990年提出、1998年正式發(fā)表的共識算法也是歷史上第一個被廣泛認可的容錯共識算法。它解決的問題是在異步通信、節(jié)點可能宕機的環(huán)境下如何讓多個節(jié)點對同一個值比如某條日志記錄的序號、某個配置項的值達成一致。Paxos的核心設計是引入提議者Proposer、接受者Acceptor和學習者Learner三種角色通過兩輪RPCPrepare和Accept來保證一旦某個值被選定后續(xù)所有提議都只能提議同樣的值。安全性Safety由法定人數(shù)Quorum機制保證——任何兩個法定人數(shù)的交集不為空所以不會被同時選出兩個不同的值。但Paxos的臭名昭著在于它極其抽象工程實現(xiàn)的門檻極高。Lamport原始的論文用議會提案做類比理解起來簡直是一種折磨。而且Paxos本身只解決單值共識真實系統(tǒng)要復制日志、選主、做成員變更還得在Paxos之上疊加大量工程細節(jié)。多PaxosMulti-Paxos雖然實際應用很廣Google的Chubby、Spanner內(nèi)部都用了類Paxos協(xié)議但因為沒有一篇公認的、可以直接照著寫的權(quán)威實現(xiàn)文檔各家實現(xiàn)五花八門團隊之間交流起來特別費勁。4.2 Raft的重新設計可理解性優(yōu)先Raft的作者Diego Ongaro和John Ousterhout在2014年發(fā)表論文《In Search of an Understandable Consensus Algorithm》開頭就直說了Paxos正確但不夠可理解所以我們設計了一個更容易理解、更適合教學和工程實現(xiàn)的共識算法。目標就是可理解性優(yōu)先把共識問題拆成相對獨立的子問題逐一解決。Raft跟Paxos最大的區(qū)別是先選主再復制。Raft把節(jié)點分成Leader、Follower、Candidate三種狀態(tài)正常情況下只有一個Leader所有寫請求都經(jīng)過Leader由Leader把日志條目復制給Follower提交后返回成功。這樣整個共識過程從多個提議者互相競爭變成了單一Leader負責推進邏輯線特別清晰。下面我詳細拆Raft的幾個核心機制這部分建議你找個本子記一下面試和實戰(zhàn)都經(jīng)常考。5. Raft算法核心機制逐層拆解5.1 領導者選舉Raft的班長機制Raft把時間劃分成一個個任期Term每個任期最多對應一個Leader。所有節(jié)點啟動時都是Follower如果在一段時間內(nèi)沒收到Leader的心跳Heartbeat它就會變成Candidate給自己currentTerm加1然后發(fā)起選舉。選舉過程這樣的Candidate先投自己一票然后向其他節(jié)點廣播RequestVote RPC。每個節(jié)點在一個任期里只能投一票收到投票請求時如果對方的日志至少不比自己舊后面會細說并且自己還沒有投過票就投給對方。候選人拿到大多數(shù)節(jié)點N/21的票數(shù)就當選Leader成為Leader后立即開始周期性發(fā)送心跳Heartbeat告訴其他節(jié)點我活著繼續(xù)保持Follower身份。選舉的關(guān)鍵參數(shù)是隨機超時時間。每個節(jié)點的選舉超時是在固定區(qū)間論文推薦150ms到300ms內(nèi)隨機選擇的。為什么要隨機如果所有節(jié)點同時超時就會同時發(fā)起選舉票數(shù)分散誰都當不上Leader然后反復選舉系統(tǒng)一直震蕩。隨機化之后總有一個節(jié)點先超時它發(fā)起選舉時其他節(jié)點還在等待票基本都會投給它這樣就能快速穩(wěn)定地選出Leader。這里有個工程細節(jié)實際的超時時間不能離心跳間隔太近否則網(wǎng)絡抖動就會引發(fā)頻繁選舉。我推薦心跳間隔在100ms到500ms之間選舉超時設為心跳間隔的3到5倍。比如心跳200ms選舉超時600ms到1000ms之間隨機。調(diào)得太小一有網(wǎng)絡毛刺就觸發(fā)選舉調(diào)得太大Leader掛了之后的恢復時間又變長。5.2 日志復制讓所有節(jié)點保持同步選出了Leader接下來就是日志復制?？蛻舳说乃袑懻埱蠖及l(fā)送給LeaderLeader先把請求封裝成一條日志條目Log Entry里面包含任期號、索引、命令等字段然后并行發(fā)給所有Follower。Follower收到AppendEntries RPC日志復制請求做一系列一致性檢查它會確認前一條日志的任期和索引是否跟自己的日志匹配只有匹配才接受新日志條目。為什么這么嚴格因為日志必須保持嚴格有序任何跳號或沖突都可能導致狀態(tài)機應用出問題。這里有個重點日志提交Commit才意味著生效。Leader只有確認某條日志已經(jīng)被復制到了大多數(shù)節(jié)點Quorum才能更新commitIndex并把這條日志應用到狀態(tài)機Apply然后才向客戶端返回成功。也就是說只要一個寫操作被大多數(shù)節(jié)點接收了即使其他節(jié)點暫時落后這條日志也已經(jīng)穩(wěn)了——因為后續(xù)任何新的Leader選舉出來它的日志一定包含這條記錄。我在實際調(diào)試Raft實現(xiàn)時最常遇到的問題就是日志覆蓋Overwrite。Raft允許Leader通過檢查日志的任期和索引讓Follower刪除并覆蓋掉那些沖突的日志條目。很多人剛學的時候不理解刪日志不是破壞一致性嗎其實不會。因為沖突的日志本來就沒被提交過未提交的日志是不穩(wěn)定的刪掉它們不會影響已提交的狀態(tài)。這個機制保證了最終所有節(jié)點日志收斂到和Leader一致。5.3 安全性保證為什么不會選錯日志復制看起來簡單但有個致命問題怎么保證新選出的Leader一定擁有所有已提交的日志如果沒有這個保證新Leader可能會覆蓋掉已經(jīng)提交的數(shù)據(jù)導致系統(tǒng)丟失數(shù)據(jù)。Raft用兩個規(guī)則解決了這個問題。第一是選舉限制Candidate在發(fā)起選舉時必須帶上自己日志的最新任期和索引。收到投票請求的節(jié)點會比較自己和對方的日志新鮮度如果對方的最后一條日志任期比自己的新或者任期相同但索引更大說明對方日志更完整就把票投給它。這樣日志更完整的節(jié)點更容易勝出確保新Leader至少不落后于大多數(shù)節(jié)點。第二是提交限制Leader只能直接提交當前任期的日志對于之前任期的日志必須等當前任期有一條日志提交了才能間接提交之前的日志。這個規(guī)則比較繞但非常關(guān)鍵。假設Leader在Term 2復制了一條日志到大多數(shù)節(jié)點但隨后宕機了Term 3的新Leader可能并不包含這條日志因為它是之前任期未提交的。如果Term 3的Leader擅自把Term 2的日志標記為提交就相當于提交了一個自己都沒有的日志這絕對不行。所以Raft規(guī)定舊日志只能通過當前任期的日志間接確認提交。這兩個規(guī)則配在一起Raft就具備了完整的安全性Safety任何已提交的日志條目一定存在于之后任意任期的Leader的日志中。這就保證了數(shù)據(jù)不會丟也不會被覆蓋。5.4 成員變更生產(chǎn)環(huán)境繞不開的難題Raft的另一個關(guān)鍵機制是成員變更Membership Change。這在生產(chǎn)環(huán)境里是真的繞不開——你要擴縮容、替換故障節(jié)點都涉及成員變更。Raft論文里給出的是**聯(lián)合共識Joint Consensus**方案把成員變更拆成兩個階段。第一階段新老配置同時生效任何決策都需要老配置的Quorum和新配置的Quorum都同意第二階段確認穩(wěn)定后完全切換到新配置。這個方案理論上很完美但實現(xiàn)起來還是有點復雜。工程上更常用的簡化版本是單節(jié)點變更Single-Server Membership Change每次只添加或刪除一個節(jié)點不搞聯(lián)合共識。論文后續(xù)附錄證明了在每次只變更一個節(jié)點的情況下系統(tǒng)的安全性依然能得到保證。etcd、Hashicorp Raft庫基本都是走這個路線。我在實踐里建議優(yōu)先選單節(jié)點變更實現(xiàn)復雜度低出問題的概率小得多。6. 工程實踐分布式事務與一致性算法在真實系統(tǒng)中的配合聊了這么多理論最后落到工程上。很多人有個誤解學了Raft是不是就該自己寫一個共識模塊我的建議是除非你想造輪子否則生產(chǎn)環(huán)境千萬別自己實現(xiàn)Raft。Raft的難度不在算法本身而在邊角場景——磁盤故障、網(wǎng)絡抖動、時鐘漂移、快照、配置變更任何一個都能讓一個看似正確的實現(xiàn)翻車。實際工程中Raft早就被封裝成了可靠的基礎組件。etcd的raft庫Go、Hashicorp的Raft庫Go、百度的braftC、螞蟻的sofa-jraftJava都是成熟選擇。你在業(yè)務代碼里要做的不是重寫Raft而是基于這些庫把共識組的能力用起來。比如用etcd做分布式鎖、用ZooKeeper做元數(shù)據(jù)管理、用TiKV或CockroachDB做分布式數(shù)據(jù)庫這些系統(tǒng)內(nèi)部都用了Raft或類Paxos算法你不需要操心內(nèi)部實現(xiàn)但要理解它們的行為模型什么操作是線性的、什么操作是最終一致的、分區(qū)時會發(fā)生什么。另外分布式事務模型在微服務架構(gòu)里很少單獨使用一般會配合本地消息表重試對賬的組合拳。比如我做過的一個供應鏈項目訂單創(chuàng)建走本地消息表發(fā)事件庫存扣減走Saga編排資金扣減走TCC。外圍架設一套定時對賬任務每隔一段時間掃描兩邊數(shù)據(jù)發(fā)現(xiàn)不一致就告警并自動補償。這套組合下來絕大多數(shù)數(shù)據(jù)不一致問題都能在秒級到分鐘級內(nèi)收斂關(guān)鍵時刻用對賬兜底比純追求強一致要穩(wěn)妥得多。7. 常見問題與排查經(jīng)驗7.1 Raft集群頻繁選舉Leader怎么辦這是Raft集群最常見的問題。先看心跳間隔和選舉超時配置是否合理——心跳太慢或超時太短都會導致誤判。其次是網(wǎng)絡延遲和抖動如果節(jié)點間延遲超過心跳間隔Follower就會認為Leader掛了。排查手段包括查CPU和磁盤IORaft需要持久化日志磁盤慢會導致心跳RPC處理延遲、抓包看心跳間隔的P99延遲、檢查是否存在GC停頓JVM進程Full GC會卡住心跳響應。7.2 2PC協(xié)調(diào)者宕機事務卡死怎么辦生產(chǎn)環(huán)境里2PC協(xié)調(diào)者宕機是最惡心的場景之一因為所有參與者都在等協(xié)調(diào)者發(fā)最終決定。解決思路一般是超時回查。協(xié)調(diào)者把每個事務的狀態(tài)持久化到本地存儲恢復后根據(jù)事務日志重新決策參與者在等待協(xié)調(diào)者響應超時后主動向協(xié)調(diào)者發(fā)起狀態(tài)查詢。在MySQL XA等實現(xiàn)里這個機制是內(nèi)置的。如果你的自研方案沒有狀態(tài)持久化和回查那這個2PC根本不具備上線條件。7.3 Saga補償操作沒有冪等導致重復扣款Saga的補償執(zhí)行不保證只執(zhí)行一次網(wǎng)絡重試、執(zhí)行器重啟都可能讓同一個補償動作被執(zhí)行多次。解決方案是對每個補償操作打上全局唯一的事務ID在數(shù)據(jù)庫里用唯一索引去重或者在操作前先查詢補償記錄是否已存在。這里我推薦一個實踐所有補償操作必須是冪等的而且要能處理補償本身也失敗的情況——需要把失敗的補償記錄下來交給人工或?qū)~任務處理不能讓它無限重試打到下游。7.4 常見問題速查表問題可能原因排查方法Raft選主頻繁心跳間隔過短、網(wǎng)絡抖動、磁盤慢檢查心跳配置、抓包統(tǒng)計延遲、觀察GC停頓數(shù)據(jù)短暫不一致AP系統(tǒng)正常特性確認業(yè)務容忍度檢查補償任務是否運行正常TCC的Confirm重復觸發(fā)報錯缺乏冪等控制用事務ID唯一索引做冪等重復執(zhí)行返回成功本地消息表中的消息始終投遞不成功MQ異常、序列化失敗、消息體過大查看MQ是否可用、檢查消息表狀態(tài)、增加重試退避Saga事務回滾后業(yè)務流程中斷補償時序不對、補償未執(zhí)行梳理補償依賴順序補充補償失敗告警和人工介入機制7.5 一致性排查的通用方法論排查數(shù)據(jù)一致性問題時我有一套固定的三段法先確認時間線哪個操作先發(fā)生哪個后發(fā)生操作順序?qū)Σ粚υ俅_認狀態(tài)線每條數(shù)據(jù)在各個節(jié)點的當前狀態(tài)是什么是否有版本號或時間戳輔助判斷最后確認日志線操作日志、事務日志、消息投遞記錄是否完整有沒有丟失或重復。把三條線疊在一起比對80%的不一致問題都能定位到具體環(huán)節(jié)。剩下的20%往往是某些節(jié)點狀態(tài)機應用邏輯的bug那就需要靠對賬系統(tǒng)跑批來兜底了。8. 從理論到落地我的幾點體會說到底CAP定理、分布式事務模型、Raft算法這些東西從來都不是孤立的知識點。它們串起來其實是一條完整的決策鏈先認清分布式系統(tǒng)的故障模型再想清楚業(yè)務到底需要什么程度的一致性然后選擇合適的事務模型最后用讀寫路徑上的核心組件數(shù)據(jù)庫、消息隊列、共識服務把模型落地。我自己踩過最大的坑就是一開始總想一步到位搞強一致覺得最終一致是偷懶。后來在真實的電商支付鏈路里做壓測才發(fā)現(xiàn)強一致方案的代價不只是性能還有運維復雜度——你要處理協(xié)調(diào)者狀態(tài)持久化、處理故障恢復、處理網(wǎng)絡分區(qū)下的僵局。業(yè)務側(cè)根本等不起。反而是Saga加消息補償?shù)姆桨概浜贤晟频膶~監(jiān)控既保證了最終不丟數(shù)據(jù)又扛得住高并發(fā)流量。Raft那套東西真正吃透之后有個額外的好處你能讀懂etcd、TiKV這些基礎組件在極端情況下的行為邏輯了。比如為什么etcd在Leader選舉期間不能寫、為什么TiKV的分區(qū)容錯行為是優(yōu)先保證已提交數(shù)據(jù)的安全這些都能從Raft的機制里找到答案。知其所以然排查問題的時候就不慌。最后分享一個小技巧學習分布式事務和一致性算法別只看理論一定要親手搭一個環(huán)境實驗一下。用Docker拉一個三節(jié)點的etcd停掉一個節(jié)點看看讀寫表現(xiàn)再停掉兩個節(jié)點看看或者起一個Seata服務把一個TCC事務跑到一半斷掉網(wǎng)絡看看補償怎么觸發(fā)。這些實驗比讀十篇博客都管用。理論給你地圖實驗給你腳感兩者都到位了分布式系統(tǒng)里的這片坑你才算是真正趟明白了。