1.分布式解決方案

分布式事務(wù)的實現(xiàn)主要有以下 5 種方案：

XA 方案

TCC 方案

本地消息表

可靠消息最終一致性方案

最大努力通知方案

1.1兩階段提交方案/XA方案

所謂的 XA 方案，即：兩階段提交，有一個事務(wù)管理器的概念，負責協(xié)調(diào)多個數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問問各個數(shù)據(jù)庫你準備好了嗎？如果每個數(shù)據(jù)庫都回復 ok，那么就正式提交事務(wù)，在各個數(shù)據(jù)庫上執(zhí)行操作；如果任何其中一個數(shù)據(jù)庫回答不 ok，那么就回滾事務(wù)。

這個方案，我們很少用，一般來說某個系統(tǒng)內(nèi)部如果出現(xiàn)跨多個庫的這么一個操作，是不合規(guī)的。我可以給大家介紹一下， 現(xiàn)在微服務(wù)，一個大的系統(tǒng)分成幾十個甚至幾百個服務(wù)。一般來說，我們的規(guī)定和規(guī)范，是要求每個服務(wù)只能操作自己對應(yīng)的一個數(shù)據(jù)庫。

如果你要操作別的服務(wù)對應(yīng)的庫，不允許直連別的服務(wù)的庫，違反微服務(wù)架構(gòu)的規(guī)范，你隨便交叉胡亂訪問，幾百個服務(wù)的話，全體亂套，這樣的一套服務(wù)是沒法管理的，沒法治理的，可能會出現(xiàn)數(shù)據(jù)被別人改錯，自己的庫被別人寫掛等情況。

如果你要操作別人的服務(wù)的庫，你必須是通過調(diào)用別的服務(wù)的接口來實現(xiàn)，絕對不允許交叉訪問別人的數(shù)據(jù)庫。

1.2TCC 方案

TCC 的全稱是：Try、Confirm、Cancel。

Try 階段：這個階段說的是對各個服務(wù)的資源做檢測以及對資源進行鎖定或者預留。

Confirm 階段：這個階段說的是在各個服務(wù)中執(zhí)行實際的操作。

Cancel 階段：如果任何一個服務(wù)的業(yè)務(wù)方法執(zhí)行出錯，那么這里就需要進行補償，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作。（把那些執(zhí)行成功的回滾）

這種方案說實話幾乎很少人使用，我們用的也比較少，但是也有使用的場景。因為這個事務(wù)回滾實際上是嚴重依賴于你自己寫代碼來回滾和補償了，會造成補償代碼巨大，非常之惡心。

比如說我們，一般來說跟錢相關(guān)的，跟錢打交道的，支付、交易相關(guān)的場景，我們會用 TCC，嚴格保證分布式事務(wù)要么全部成功，要么全部自動回滾，嚴格保證資金的正確性，保證在資金上不會出現(xiàn)問題。

而且最好是你的各個業(yè)務(wù)執(zhí)行的時間都比較短。

但是說實話，一般盡量別這么搞，自己手寫回滾邏輯，或者是補償邏輯，實在太惡心了，那個業(yè)務(wù)代碼是很難維護的。

1.3本地消息表

本地消息表其實是國外的 ebay 搞出來的這么一套思想。

這個大概意思是這樣的：

A 系統(tǒng)在自己本地一個事務(wù)里操作同時，插入一條數(shù)據(jù)到消息表；

接著 A 系統(tǒng)將這個消息發(fā)送到 MQ 中去；

B 系統(tǒng)接收到消息之后，在一個事務(wù)里，往自己本地消息表里插入一條數(shù)據(jù)，同時執(zhí)行其他的業(yè)務(wù)操作，如果這個消息已經(jīng)被處理過了，那么此時這個事務(wù)會回滾，這樣保證不會重復處理消息；

B 系統(tǒng)執(zhí)行成功之后，就會更新自己本地消息表的狀態(tài)以及 A 系統(tǒng)消息表的狀態(tài)；

如果 B 系統(tǒng)處理失敗了，那么就不會更新消息表狀態(tài)，那么此時 A 系統(tǒng)會定時掃描自己的消息表，如果有未處理的消息，會再次發(fā)送到 MQ 中去，讓 B 再次處理；

這個方案保證了最終一致性，哪怕 B 事務(wù)失敗了，但是 A 會不斷重發(fā)消息，直到 B 那邊成功為止。

這個方案說實話最大的問題就在于嚴重依賴于數(shù)據(jù)庫的消息表來管理事務(wù)啥的，如果是高并發(fā)場景咋辦呢？咋擴展呢？所以一般確實很少用。

1.4可靠消息最終一致性方案

這個的意思，就是干脆不要用本地的消息表了，直接基于 MQ 來實現(xiàn)事務(wù)。比如阿里的 RocketMQ 就支持消息事務(wù)。

大概的意思就是：

A 系統(tǒng)先發(fā)送一個 prepared 消息到 mq，如果這個 prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了；

如果這個消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)，如果成功就告訴 mq 發(fā)送確認消息，如果失敗就告訴 mq 回滾消息；

如果發(fā)送了確認消息，那么此時 B 系統(tǒng)會接收到確認消息，然后執(zhí)行本地的事務(wù)；

mq 會自動定時輪詢所有 prepared 消息回調(diào)你的接口，問你，這個消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認的消息，是繼續(xù)重試還是回滾？一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了，那么這里也回滾吧。這個就是避免可能本地事務(wù)執(zhí)行成功了，而確認消息卻發(fā)送失敗了。

這個方案里，要是系統(tǒng) B 的事務(wù)失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業(yè)務(wù)進行回滾，比如 B 系統(tǒng)本地回滾后，想辦法通知系統(tǒng) A 也回滾；或者是發(fā)送報警由人工來手工回滾和補償。

這個還是比較合適的，目前國內(nèi)互聯(lián)網(wǎng)公司大都是這么玩兒的，要不你舉用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。

先發(fā)一半消息，然后執(zhí)行事務(wù)，執(zhí)行成功和失敗都會發(fā)送確認消息（告知mq前面的消息有效還是作廢），如果確認消息失敗則mq會定時回查該事務(wù)狀態(tài)。

1.5最大努力通知方案

這個方案的大致意思就是：

系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個消息到 MQ；

這里會有個專門消費 MQ 的最大努力通知服務(wù)，這個服務(wù)會消費 MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個內(nèi)存隊列也可以，接著調(diào)用系統(tǒng) B 的接口；

要是系統(tǒng) B 執(zhí)行成功就 ok 了；要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時嘗試重新調(diào)用系統(tǒng) B，反復 N 次，最后還是不行就放棄。

2.分布式框架

當然如果你愿意，你可以參考可靠消息最終一致性方案來自己實現(xiàn)一套分布式事務(wù)，比如基于 RocketMQ 來玩兒。

友情提示一下，RocketMQ 3.2.6 之前的版本，是可以按照上面的思路來的，但是之后接口做了一些改變，我這里不再贅述了。

你找一個嚴格資金要求絕對不能錯的場景，你可以說你是用的 TCC 方案；如果是一般的分布式事務(wù)場景，訂單插入之后要調(diào)用庫存服務(wù)更新庫存，庫存數(shù)據(jù)沒有資金那么的敏感，可以用可靠消息最終一致性方案。

如果你真的被問到，可以這么說，我們某某特別嚴格的場景，用的是 TCC 來保證強一致性；然后其他的一些場景基于阿里的 RocketMQ 來實現(xiàn)分布式事務(wù)。

你們公司是如何處理分布式事務(wù)的？

要是系統(tǒng) B 執(zhí)行成功就 ok 了；要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時嘗試重新調(diào)用系統(tǒng) B，反復 N 次，最后還是不行就放棄。

這里會有個專門消費 MQ 的最大努力通知服務(wù)，這個服務(wù)會消費 MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個內(nèi)存隊列也可以，接著調(diào)用系統(tǒng) B 的接口；

系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個消息到 MQ；

這個方案的大致意思就是：

? 1）automiko框架

? ? ? 只適用于單服務(wù)多數(shù)據(jù)源情景

? ? ? 原理：將兩個事務(wù)操作合并到一個事務(wù)。

2）Hmily框架

@Override

? public Object handler(ProceedingJoinPoint point, TccTransactionContext context) throws Throwable {

? ? ? Object returnValue;

? ? ? try {

? ? ? ? ? tccTransactionManager.begin();

? ? ? ? ? try {

? ? ? ? ? ? ? //發(fā)起調(diào)用 執(zhí)行try方法

? ? ? ? ? ? ? returnValue = point.proceed();

? ? ? ? ? } catch (Throwable throwable) {

? ? ? ? ? ? ? //異常執(zhí)行cancel

? ? ? ? ? ? ? tccTransactionManager.cancel();

? ? ? ? ? ? ? throw throwable;

? ? ? ? ? }

? ? ? ? ? //try成功執(zhí)行confirm confirm 失敗的話，那就只能走本地補償

? ? ? ? ? tccTransactionManager.confirm();

? ? ? } finally {

? ? ? ? ? tccTransactionManager.remove();

? ? ? }

? ? ? return returnValue;

? }

通過加上注解，發(fā)起方會先調(diào)用被調(diào)用方的try方法，成功則執(zhí)行被調(diào)用方的confirm方法，失敗執(zhí)行被調(diào)用方的cancel方法。

詳情：https://yu199195.github.io/categories/hmily-tcc/

? 3）阿里fescar框架

? ? ? 原理：

? ? ? 在第一階段，分析sql的得到undo日志，事務(wù)提交的時候?qū)I(yè)務(wù)數(shù)據(jù)更新和undo日志的插入? ? ? ?

? ? （一個專門的回滾日志表）通過本地事務(wù)提交，所以本地數(shù)據(jù)庫必須支持事務(wù)。

? ? 第二階段：如果第一階段有某個服務(wù)異常，那么就利用回滾日志恢復原來的情況。

詳情：http://seata.io/zh-cn/docs/overview/what-is-seata.html

? ? 4）LCN框架

? ? 由transaction manager統(tǒng)一提交或回滾各事務(wù)，如果某個子模塊事務(wù)提交失敗則會有補償機制繼續(xù)提交。

4）

3.tcc和xa關(guān)系

3.1.TTC

? try

? 開始事務(wù)，鎖住資源，但不提交

confirm

? 如果各個服務(wù)都try成功，則config，提交事務(wù)。

這個時候，就需要依靠 TCC 分布式事務(wù)框架來推動后續(xù)的執(zhí)行了。這里簡單提一句，如果你要玩兒 TCC 分布式事務(wù)，必須引入一款 TCC 分布式事務(wù)框架，比如國內(nèi)開源的 ByteTCC、Himly、TCC-transaction。

cancel

? 如果有一個服務(wù)不成功，則cancel，取消事務(wù)，釋放資源