兩階段提交方案/XA方案
1、多個任務都先鎖定自己需要的資源，然後發送準備消息給事務管理器
2、事務管理器收到所有任務的準備信息後發送確認信息給任務，可以執行
3、任務只能使用之前聲明佔有的資源
TCC 方案
TCC 的全稱是：Try、Confirm、Cancel。
- Try 階段：這個階段說的是對各個服務的資源做檢測以及對資源進行鎖定或者預留。
- Confirm階段：這個階段說的是在各個服務中執行實際的操作。
- Cancel 階段：如果任何一個服務的業務方法執行出錯，那麼這裏就需要進行補償，就是執行已經執行成功的業務邏輯的回滾操作。（把那些執行成功的回滾）
這種方案說實話幾乎很少人使用，我們用的也比較少，但是也有使用的場景。因爲這個事務回滾實際上是嚴重依賴於你自己寫代碼來回滾和補償了，會造成補償代碼巨大，非常之噁心。
一般來說跟錢相關的，跟錢打交道的，支付、交易相關的場景，我們會用 TCC，嚴格保證分佈式事務要麼全部成功，要麼全部自動回滾，嚴格保證資金的正確性，保證在資金上不會出現問題。
本地消息表
本地消息表其實是國外的 ebay 搞出來的這麼一套思想。
這個大概意思是這樣的：
- A 系統在自己本地一個事務裏操作同時，插入一條數據到消息表；
- 接着 A 系統將這個消息發送到 MQ 中去；
- B 系統接收到消息之後，在一個事務裏，往自己本地消息表裏插入一條數據，同時執行其他的業務操作，如果這個消息已經被處理過了，那麼此時這個事務會回滾，這樣保證不會重複處理消息；
- B 系統執行成功之後，就會更新自己本地消息表的狀態以及 A 系統消息表的狀態；
- 如果 B 系統處理失敗了，那麼就不會更新消息表狀態，那麼此時 A 系統會定時掃描自己的消息表，如果有未處理的消息，會再次發送到 MQ 中去，讓 B 再次處理；
- 這個方案保證了最終一致性，哪怕 B 事務失敗了，但是 A 會不斷重發消息，直到 B 那邊成功爲止。
這個方案說實話最大的問題就在於嚴重依賴於數據庫的消息表來管理事務啥的，會導致如果是高併發場景咋辦呢？咋擴展呢？所以一般確實很少用。
可靠消息最終一致性方案
這個的意思，就是乾脆不要用本地的消息表了，直接基於 MQ 來實現事務。比如阿里的 RocketMQ 就支持消息事務。
1.先發送消息到可靠消息隊列，等到本地任務執行完畢再發送確認信息到隊列，如果確認信息超時或者其他，隊列會定時輪詢本地任務是否成功，成功則確認發送信息，失敗則回滾。
2.發送給下游服務後，如果信息超時或者發送失敗，那麼則會重新發送，下游服務則會保證消息的冪等性，不會重複執行。
大概的意思就是：
- A 系統先發送一個 prepared 消息到 mq，如果這個 prepared 消息發送失敗那麼就直接取消操作別執行了；
- 如果這個消息發送成功過了，那麼接着執行本地事務，如果成功就告訴 mq 發送確認消息，如果失敗就告訴 mq 回滾消息；
如果發送了確認消息，那麼此時 B 系統會接收到確認消息，然後執行本地的事務； - mq 會自動定時輪詢所有 prepared 消息回調你的接口，問你，這個消息是不是本地事務處理失敗了，所有沒發送確認的消息，是繼續重試還是回滾？一般來說這裏你就可以查下數據庫看之前本地事務是否執行，如果回滾了，那麼這裏也回滾吧。這個就是避免可能本地事務執行成功了，而確認消息卻發送失敗了。
- 這個方案裏，要是系統 B 的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行回滾，比如 B 系統本地回滾後，想辦法通知系統 A 也回滾；或者是發送報警由人工來手工回滾和補償。
- 這個還是比較合適的，目前國內互聯網公司大都是這麼玩兒的，要不你舉用 RocketMQ 支持的，要不你就自己基於類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。
最大努力通知方案
這個方案的大致意思就是：
- 系統 A 本地事務執行完之後，發送個消息到 MQ；
- 這裏會有個專門消費 MQ 的最大努力通知服務，這個服務會消費 MQ 然後寫入數據庫中記錄下來，或者是放入個內存隊列也可以，接着調用系統 B 的接口；
- 要是系統 B 執行成功就 ok 了；要是系統 B 執行失敗了，那麼最大努力通知服務就定時嘗試重新調用系統 B，反覆 N 次，最後還是不行就放棄。