分布式事務(wù)一致性解決方案對(duì)比在微服務(wù)架構(gòu)與分布式系統(tǒng)日益普及的今天業(yè)務(wù)邏輯往往跨越多個(gè)獨(dú)立的服務(wù)與數(shù)據(jù)庫。如何保證跨服務(wù)的數(shù)據(jù)操作具備原子性、一致性、隔離性和持久性ACID成為系統(tǒng)設(shè)計(jì)的關(guān)鍵挑戰(zhàn)。分布式事務(wù)一致性解決方案應(yīng)運(yùn)而生它們各自基于不同的設(shè)計(jì)哲學(xué)在性能、一致性強(qiáng)度、復(fù)雜度與適用場景之間做出權(quán)衡。本文將深入對(duì)比幾種主流的解決方案。二階段提交2PC二階段提交是最經(jīng)典的分布式事務(wù)協(xié)議其核心思想是將事務(wù)提交過程分為兩個(gè)階段由協(xié)調(diào)者Coordinator統(tǒng)一調(diào)度。第一階段為“準(zhǔn)備階段”協(xié)調(diào)者向所有參與者Participant發(fā)送準(zhǔn)備請(qǐng)求參與者執(zhí)行本地事務(wù)的所有操作如寫日志、鎖定資源但暫不提交并反饋是否可以提交。第二階段為“提交階段”若所有參與者均反饋“可以提交”協(xié)調(diào)者則發(fā)送提交指令所有參與者正式提交若有任一參與者反饋“不可提交”協(xié)調(diào)者則發(fā)送回滾指令所有參與者進(jìn)行回滾。2PC的主要優(yōu)勢在于其強(qiáng)一致性保證實(shí)現(xiàn)了ACID特性在分布式場景下的延伸。然而其缺點(diǎn)顯著同步阻塞導(dǎo)致性能低下協(xié)調(diào)者單點(diǎn)故障可能造成數(shù)據(jù)不一致或長時(shí)間阻塞數(shù)據(jù)鎖定時(shí)間長影響系統(tǒng)并發(fā)吞吐。因此2PC適用于對(duì)一致性要求極高、且參與方不多、事務(wù)執(zhí)行時(shí)間較短的場景如傳統(tǒng)金融系統(tǒng)的內(nèi)部模塊間事務(wù)。三階段提交3PC為緩解2PC的阻塞問題三階段提交協(xié)議被提出。它在2PC的基礎(chǔ)上增加了“預(yù)提交階段”將整個(gè)過程分為CanCommit、PreCommit和DoCommit三個(gè)階段。在CanCommit階段協(xié)調(diào)者詢問參與者是否具備執(zhí)行條件此階段不鎖定資源可提前發(fā)現(xiàn)無法執(zhí)行的事務(wù)。PreCommit階段類似于2PC的準(zhǔn)備階段但參與者此時(shí)仍未鎖定資源。DoCommit階段執(zhí)行最終提交或回滾。3PC通過引入超時(shí)機(jī)制和預(yù)提交階段降低了協(xié)調(diào)者單點(diǎn)故障時(shí)的阻塞風(fēng)險(xiǎn)。若協(xié)調(diào)者在PreCommit后故障參與者在一定超時(shí)后可直接提交因?yàn)樗袇⑴c者已達(dá)成“預(yù)備提交”共識(shí)。這提高了系統(tǒng)的可用性。然而3PC并未完全解決數(shù)據(jù)不一致問題例如網(wǎng)絡(luò)分區(qū)可能導(dǎo)致部分提交且協(xié)議更為復(fù)雜通信次數(shù)增多。其適用場景與2PC類似但對(duì)可用性要求稍高。TCCTry-Confirm-CancelTCC是一種基于業(yè)務(wù)補(bǔ)償?shù)娜嵝允聞?wù)解決方案。它將一個(gè)分布式事務(wù)拆分為三個(gè)操作Try階段嘗試執(zhí)行完成所有業(yè)務(wù)檢查并預(yù)留必要的業(yè)務(wù)資源例如凍結(jié)庫存、預(yù)扣金額。Confirm階段確認(rèn)執(zhí)行真正執(zhí)行業(yè)務(wù)操作使用Try階段預(yù)留的資源。此操作需保證冪等性。Cancel階段取消執(zhí)行釋放Try階段預(yù)留的資源也需保證冪等性。TCC由業(yè)務(wù)邏輯層面實(shí)現(xiàn)因此具有很高的靈活性可以避免數(shù)據(jù)庫層面的長事務(wù)鎖定提升系統(tǒng)吞吐量。其核心思想是“最終一致性”允許中間狀態(tài)存在。然而TCC對(duì)業(yè)務(wù)侵入性強(qiáng)每個(gè)服務(wù)都需要實(shí)現(xiàn)Try、Confirm、Cancel三個(gè)接口開發(fā)復(fù)雜度高。同時(shí)資源預(yù)留可能影響用戶體驗(yàn)如資金被凍結(jié)。TCC適用于執(zhí)行時(shí)間較長、對(duì)最終一致性可接受、且業(yè)務(wù)模型可清晰定義為“兩階段”的互聯(lián)網(wǎng)場景如電商訂單、酒店預(yù)訂。Saga模式Saga模式也是一種補(bǔ)償型方案但其思想與TCC不同。它將一個(gè)長事務(wù)拆分為一系列本地子事務(wù)每個(gè)子事務(wù)正常提交并更新數(shù)據(jù)庫。同時(shí)為每個(gè)子事務(wù)配置一個(gè)對(duì)應(yīng)的補(bǔ)償事務(wù)用于撤銷該子事務(wù)造成的影響。執(zhí)行時(shí)按順序執(zhí)行所有子事務(wù)。若所有子事務(wù)成功則事務(wù)完成。若其中某個(gè)子事務(wù)失敗則按相反順序依次執(zhí)行之前所有已執(zhí)行子事務(wù)的補(bǔ)償事務(wù)進(jìn)行回滾。Saga模式的優(yōu)勢在于避免了資源長期鎖定子事務(wù)提交后即可釋放資源并發(fā)性能好。其缺點(diǎn)在于隔離性差由于子事務(wù)直接提交其他事務(wù)可能讀到中間狀態(tài)導(dǎo)致“臟讀”。通常需要通過業(yè)務(wù)設(shè)計(jì)如版本號(hào)、狀態(tài)機(jī)或應(yīng)用層鎖來彌補(bǔ)。Saga適用于業(yè)務(wù)流程長、步驟多、且每個(gè)步驟都有明確逆操作的場景如旅行預(yù)訂訂機(jī)票、酒店失敗則依次取消?；谙㈥?duì)列的最終一致性這是一種非常流行的異步確保型方案。其核心是利用消息隊(duì)列的可靠傳遞配合本地事務(wù)表來實(shí)現(xiàn)。具體流程為1. 業(yè)務(wù)服務(wù)在執(zhí)行本地事務(wù)的同時(shí)將需要發(fā)送的消息寫入同一數(shù)據(jù)庫的“消息事件表”與業(yè)務(wù)數(shù)據(jù)在同一事務(wù)中提交。2. 由一個(gè)獨(dú)立的“消息抓取服務(wù)”定時(shí)掃描消息事件表將消息發(fā)送至消息隊(duì)列。3. 下游服務(wù)消費(fèi)消息處理業(yè)務(wù)并可能繼續(xù)產(chǎn)生新的事件。該方案通過本地事務(wù)保證了業(yè)務(wù)操作與消息記錄的原子性通過消息隊(duì)列的重試機(jī)制保證消息最終必達(dá)從而實(shí)現(xiàn)系統(tǒng)間的最終一致性。其優(yōu)點(diǎn)是非侵入、性能好、系統(tǒng)耦合度低。缺點(diǎn)是實(shí)現(xiàn)最終一致性存在延遲且需要處理消息冪等消費(fèi)。它廣泛適用于跨系統(tǒng)集成、數(shù)據(jù)同步、事件驅(qū)動(dòng)架構(gòu)等對(duì)實(shí)時(shí)一致性要求不高的場景。對(duì)比總結(jié)與選型建議| 解決方案 | 一致性強(qiáng)度 | 性能 | 復(fù)雜度 | 業(yè)務(wù)侵入性 | 典型適用場景 || :--- | :--- | :--- | :--- | :--- | :--- || 2PC | 強(qiáng)一致性 | 低 | 中 | 低 | 傳統(tǒng)金融、數(shù)據(jù)庫內(nèi)部分布式事務(wù) || 3PC | 強(qiáng)一致性優(yōu)化可用性 | 中低 | 高 | 低 | 對(duì)可用性有要求的強(qiáng)一致場景 || TCC | 最終一致性 | 高 | 高 | 高 | 電商、互聯(lián)網(wǎng)金融等可補(bǔ)償業(yè)務(wù) || Saga | 最終一致性弱隔離 | 高 | 中 | 中 | 長流程業(yè)務(wù)如訂單旅行、供應(yīng)鏈 || 消息隊(duì)列 | 最終一致性 | 高 | 中 | 低 | 跨系統(tǒng)集成、事件通知、數(shù)據(jù)同步 |在選擇分布式事務(wù)解決方案時(shí)沒有“銀彈”需綜合考量業(yè)務(wù)需求- 追求強(qiáng)一致性且容忍性能損耗可考慮2PC或其變種。- 追求高可用與高性能可接受最終一致性TCC、Saga或消息隊(duì)列方案是主流選擇。- 業(yè)務(wù)可補(bǔ)償且開發(fā)資源充足TCC提供更精細(xì)控制。- 流程長、步驟可逆Saga模式更合適。- 系統(tǒng)解耦、異步處理基于消息隊(duì)列的方案最為自然。在實(shí)踐中許多系統(tǒng)會(huì)采用混合模式例如核心交易鏈路使用TCC保證資金準(zhǔn)確而周邊日志、積分等操作采用消息隊(duì)列異步同步。理解每種方案的底層原理與代價(jià)是構(gòu)建可靠分布式系統(tǒng)的基石。