微服務(wù)架構(gòu)中分布式事務(wù)實現(xiàn)方案怎樣何取舍

提起微服務(wù)架構(gòu)，不可避免的兩個話題就是服務(wù)治理和分布式事務(wù)。數(shù)據(jù)庫和業(yè)務(wù)模塊的垂直拆分為我們帶來了系統(tǒng)性能、穩(wěn)定性和開發(fā)效率的提升的同時也引入了一些更復(fù)雜的問題，例如在數(shù)據(jù)一致性問題上，我們不再能夠依賴數(shù)據(jù)庫的本地事務(wù)，對于一系列的跨庫寫入操作，如何保證其原子性，是微服務(wù)架構(gòu)下不得不面對的問題。

1 分布式事務(wù)解決方案

針對分布式系統(tǒng)的特點，基于不同的一致性需求產(chǎn)生了不同的分布式事務(wù)解決方案，追求強一致的兩階段提交、追求最終一致性的柔性事務(wù)和事務(wù)消息等等。各種方案沒有絕對的好壞，拋開具體場景我們無法評價，更無法能做出合理選擇。在選擇分布式事務(wù)方案時，需要我們充分了解各種解決方案的原理和設(shè)計初衷，再結(jié)合實際的業(yè)務(wù)場景，從而做出科學(xué)合理的選擇。

2 強一致解決方案

2.1 兩階段提交

兩階段提交算法中有兩種角色：事務(wù)協(xié)調(diào)者和事務(wù)參與者，一個事務(wù)一般會涉及多個事務(wù)參與者，具體的兩階段過程如下圖所示：

第一階段：寫庫操作完成后協(xié)調(diào)者向所有參與者發(fā)送Prepare消息，詢問各參與者的本地事務(wù)是否可以提交，參與者根據(jù)自身情況向協(xié)調(diào)者返回可以或不可以；

第二階段：協(xié)調(diào)者收到所有參與者的反饋后，如果全部返回的是可以提交則向所有參與者發(fā)送提交事務(wù)命令。只要有一個參與者返回的是不能提交，則向所有參與者發(fā)送回滾命令。如下圖所示：

圖1 兩階段提交

在上述的兩階段模型中，事務(wù)提交過程中有可能出現(xiàn)協(xié)調(diào)者或個別參與者宕機的情況，但多數(shù)情況下參與事務(wù)的節(jié)點可以通過詢問其他節(jié)點得知事務(wù)狀態(tài)，做出正確的操作。但在極端情況下事務(wù)有可能處于未知狀態(tài)。我們分析下下面這個場景：當(dāng)協(xié)調(diào)者發(fā)送提交指令后宕機，而唯一收到提交指令的參與者完成提交后也宕機了，此時沒有節(jié)點知道事務(wù)應(yīng)該提交還是回滾，事務(wù)處于未知狀態(tài)，所以在這種極端情況下可能造成數(shù)據(jù)的不一致。針對兩階段的缺陷，又提出了三階段提交協(xié)議。

2.2  三階段提交

三階段提交是將第二階段拆分成預(yù)提交和確認(rèn)提交兩個階段。這樣在事務(wù)提交過程中，無論哪個節(jié)點宕機，只要有一個存活節(jié)點處于預(yù)提交或是提交狀態(tài)我們都可以確定事務(wù)是可以提交的（第一階段已經(jīng)確認(rèn)事務(wù)可以提交），反之如果沒有處于這兩種狀態(tài)的節(jié)點，則回滾事務(wù)。

圖2 三階段提交

從上面的分析可以看到，無論是兩階段還是三階段最后的“提交”都是一個耗時極短的操作，即使在分布式系統(tǒng)中失敗的概率也是非常小的，所以我們可以認(rèn)為兩階段提交基本能夠保證分布式事務(wù)原子性。

3 落地方案

上面介紹的只是理論基礎(chǔ)，XA規(guī)范就是基于兩階段提交的理論模型提出的分布式事務(wù)規(guī)范，規(guī)范中的資源管理器相當(dāng)于事務(wù)參與者；事務(wù)管理器相當(dāng)于事務(wù)協(xié)調(diào)者，目前很多主流的關(guān)系數(shù)據(jù)庫都實現(xiàn)了XA接口。

落地到實際應(yīng)用中我們會發(fā)現(xiàn)兩階段提交存在的一些問題：

1. 數(shù)據(jù)庫產(chǎn)品要保證數(shù)據(jù)完成性，寫入需要加鎖，所以在整個分布式事務(wù)協(xié)調(diào)過程中可能造成數(shù)據(jù)庫資源鎖定時間過長，不適合并發(fā)高以及子事務(wù)生命周期較長的業(yè)務(wù)場景；

2. XA規(guī)范要求事務(wù)管理器本地記錄事務(wù)執(zhí)行狀態(tài)，所以事務(wù)管理器作為有狀態(tài)服務(wù)不支持事務(wù)異地恢復(fù)；

XA能夠最大程度保證數(shù)據(jù)的一致性，但在高并發(fā)場景下性能衰減非常嚴(yán)重，所以在數(shù)據(jù)一致性需求上如果不是“強一致”，不建議使用。

3.1 最終一致性解決方案

在我們大多數(shù)的業(yè)務(wù)場景中，追求的都是數(shù)據(jù)的最終一致性，業(yè)界也提出了很多柔性事務(wù)的解決方案，可以很大程度上保證數(shù)據(jù)的一致性，我們可以根據(jù)實際場景來權(quán)衡使用。具體的解決方案有很多，總結(jié)其設(shè)計思路可以分為下面3種模型：

3.1.1 TCC（Try-Confirm-Cancel）

TCC將事務(wù)分為Try，Confirm，Cancel三個階段。

1. Try階段：嘗試執(zhí)行業(yè)務(wù)，預(yù)留資源；

2. Confirm階段：確認(rèn)執(zhí)行業(yè)務(wù)，使用Try階段資源；

3. Cancel階段：取消執(zhí)行業(yè)務(wù)，釋放Try階段預(yù)留的資源；

我們用一個轉(zhuǎn)賬匯款的業(yè)務(wù)場景，說明下TCC的具體過程。例如：張三給李四轉(zhuǎn)賬100元，一次轉(zhuǎn)賬業(yè)務(wù)由兩個本地事務(wù)組成：1、張三賬戶扣減100元；2、李四賬戶增加100元。

事務(wù)成功處理流程如圖3：

圖3 Try-Confirm事務(wù)成功處理流程

事務(wù)失敗處理流程如圖4：

圖4 Try-Cancel事務(wù)成功處理流程

Try階段：

1、檢查張三賬戶，滿足要求賬戶扣減100元，記錄扣減事件（預(yù)留資源）；

2、檢查李四賬戶有效性；

Confirm：

如果Try成功，李四賬戶增加100元，事務(wù)完成；

Cancel：

如果Try失敗，張三賬戶增加100元，刪除扣減事件記錄（釋放預(yù)留資源），事務(wù)取消。

從性能角度分析，TCC過程沒有對資源加鎖，對系統(tǒng)并發(fā)性能幾乎沒有影響，只是會有些額外輔助操作。需要注意，在這個模型中要保證數(shù)據(jù)一致性有兩個技術(shù)難點需要解決：

1. 需要有類似事務(wù)管理器的角色保證TCC過程的完整性；

2. Confirm和Cancel方法需要保證冪等（由于不可避免的重試操作必須要保證冪等）；

TCC對業(yè)務(wù)侵入非常大，對RD同學(xué)十分不友好，業(yè)務(wù)改造成本相當(dāng)高。

3.1.2 SAGA模型

SAGA模型把一個分布式事務(wù)拆分為多個本地事務(wù)，每個本地事務(wù)都有相應(yīng)的執(zhí)行模塊和補償模塊，當(dāng)事務(wù)中任意一個本地事務(wù)出錯時，可以通過調(diào)用對應(yīng)的補償方法恢復(fù)之前的事務(wù)，從而達(dá)到數(shù)據(jù)的最終的一致性。SAGA的事務(wù)管理器負(fù)責(zé)在事務(wù)失敗時執(zhí)行補償邏輯，可以通過調(diào)用執(zhí)行模塊的逆向操作（例如執(zhí)行子事務(wù)時同時生成逆向SQL）或調(diào)用業(yè)務(wù)開發(fā)人員提供的補償方法（需要保證補償?shù)膬绲刃裕﹣韺崿F(xiàn)。

可以看到，SAGA雖然對業(yè)務(wù)造成一定的侵入，但當(dāng)相對TCC已經(jīng)有好很多了，而且，事務(wù)管理器理論上可以做到向后補償（撤銷所有已完成操作，恢復(fù)到事務(wù)開始狀態(tài)）或向前補償（繼續(xù)完成未完成事務(wù)，使業(yè)務(wù)請求得到成功處理，更符合業(yè)務(wù)預(yù)期）。

3.1.3 MQ事務(wù)消息

MQ事務(wù)消息對分布式事務(wù)模型進(jìn)行了簡化，重點不再是保證所有子事務(wù)的原子性，而是保證本地事務(wù)和發(fā)送MQ消息的原子性，我們可以利用這一特點，將分布式事務(wù)轉(zhuǎn)化成本地事務(wù)和若干發(fā)送MQ消息的操作，然后要求消費方確保消費成功。利用MQ事務(wù)消息，在系統(tǒng)中去掉了TCC和SAGA方案中的事務(wù)管理器角色，簡化了分布式事務(wù)模型，同時這也是對業(yè)務(wù)侵入最低最友好的方案（不用提供補償接口）。

當(dāng)然這里也有兩個基本前提：

1. MQ系統(tǒng)保證消息能不丟失；

2. 消費方確保消費冪等（保證不丟失，就很難避免重復(fù)消費）。

需要注意的是，MQ事務(wù)消息簡化了事務(wù)模型、降低了業(yè)務(wù)侵入，所以對數(shù)據(jù)一致性的保證保障也就相對比較低了。

4. 總結(jié)

柔性事務(wù)解決方案中，雖然SAGA和TCC看上去可以保證數(shù)據(jù)的最終一致性，但分布式系統(tǒng)的成產(chǎn)環(huán)境復(fù)雜多變，某些情況是可以導(dǎo)致柔性事務(wù)機制失效的，所以無論使用那種方案，都需要最終的兜底策略，人工校驗，修復(fù)數(shù)據(jù)。

我們綜合對比下幾種分布式事務(wù)解決方案：

一致性保證：XA > TCC = SAGA > 事務(wù)消息

業(yè)務(wù)友好性：XA > 事務(wù)消息 > SAGA > TCC

性 能 損 耗：XA > TCC > SAGA = 事務(wù)消息

最后，在設(shè)計系統(tǒng)時我們一定要結(jié)合業(yè)務(wù)自身的一致性需求，選擇恰當(dāng)?shù)姆桨??？梢钥吹綄?shù)據(jù)一致性保障越高的方案其開發(fā)成本、維護(hù)難度和系統(tǒng)性能損耗就越大，一定不要一味的追求高大上的方案，對系統(tǒng)過度設(shè)計。

更多免費技術(shù)資料及視頻