分布式事務就是指事務的參與者、支持事務的服務器箭昵、資源服務器以及事務管理器分別位于不同的分布式系統的不同節(jié)點之上税朴。以上是百度百科的解釋，簡單的說家制，就是一次大的操作由不同的小操作組成正林，這些小的操作分布在不同的服務器上，且屬于不同的應用颤殴，分布式事務需要保證這些小操作要么全部成功觅廓，要么全部失敗。本質上來說涵但，分布式事務就是為了保證不同數據庫的數據一致性杈绸。
以商品流水賬單為例，我們拆分為商品購買系統矮瘟，訂單系統瞳脓，支付系統。
用戶看中一件商品澈侠，點擊購買劫侧。 商品購買系統響應用戶的點擊，向訂單系統插入一條訂單信息哨啃。 跳轉到支付系統完成支付烧栋。 在用戶整個購買商品的過程中，我們需要保證事件1拳球，2审姓，3在沒有異常的情況下全部執(zhí)行成功，一旦某個系統拋出異常祝峻，都需要回滾魔吐。
那么，如何保證各個子系統的操作具有一致性呢莱找？這就是我們下面提到的分布式事務的解決方案酬姆。
在這里，文章中沒有提到分布式一致性協議宋距，下面簡單列舉一下轴踱，有興趣的讀者可以參考其他詳細資料：
兩階段提交協議 三階段提交協議 Paxos協議 Raft協議 二、分布式事務的解決方案
1.兩階段提交方案/XA方案 該方案基于兩階段提交協議谚赎，因此也叫做兩階段提交方案淫僻。在該分布式系統中，其中 需要一個系統擔任協調器的角色壶唤，其他系統擔任參與者的角色雳灵。主要分為Commit-request階段和Commit階段
請求階段：首先協調器會向所有的參與者發(fā)送準備提交或者取消提交的請求，然后會收集參與者的決策闸盔。 提交階段：協調者會收集所有參與者的決策信息悯辙，當且僅當所有的參與者向協調器發(fā)送確認消息時協調器才會提交請求，否則執(zhí)行回滾或者取消請求。?
?該方案的缺陷：
同步阻塞：所有的參與者都是事務同步阻塞型的躲撰。當參與者占有公共資源時针贬，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。 單點故障：一旦協調器發(fā)生故障拢蛋，系統不可用桦他。 數據不一致：當協調器發(fā)送commit之后，有的參與者收到commit消息谆棱，事務執(zhí)行成功快压，有的沒有收到，處于阻塞狀態(tài)垃瞧，這段時間會產生數據不一致性蔫劣。 不確定性：當協調器發(fā)送commit之后，并且此時只有一個參與者收到了commit个从，那么當該參與者與協調器同時宕機之后脉幢，重新選舉的協調器無法確定該條消息是否提交成功。 XA方案的實現方式可以使用Spring+JTA來實現信姓，可以參考文章：Springboot+atomikos+jta實現分布式事務統一管理 2.TCC方案 TCC方案分為Try Confirm Cancel三個階段鸵隧，屬于補償性分布式事務。
Try：嘗試待執(zhí)行的業(yè)務 這個過程并未執(zhí)行業(yè)務意推，只是完成所有業(yè)務的一致性檢查豆瘫，并預留好執(zhí)行所需的全部資源 Confirm：執(zhí)行業(yè)務 這個過程真正開始執(zhí)行業(yè)務，由于Try階段已經完成了一致性檢查菊值，因此本過程直接執(zhí)行外驱，而不做任何檢查。并且在執(zhí)行的過程中腻窒，會使用到Try階段預留的業(yè)務資源昵宇。 Cancel：取消執(zhí)行的業(yè)務 若業(yè)務執(zhí)行失敗，則進入Cancel階段儿子，它會釋放所有占用的業(yè)務資源瓦哎，并回滾Confirm階段執(zhí)行的操作。 以一個電商系統用戶購買商品的流水線為例柔逼。
Try階段：?
?在Try階段成功之后進入Confirm階段蒋譬，如有任何異常，進入Cancel階段愉适。
Confirm階段?
?Cancel階段 假設庫存扣減失敗犯助，此時需要回滾取消事務。?
?TCC方案適用于一致性要求極高的系統中维咸，比如金錢交易相關的系統中剂买，不過可以看出惠爽，其基于補償的原理，因此瞬哼，需要編寫大量的補償事務的代碼婚肆，比較冗余。不過現有開源的TCC框架倒槐，比如TCC-transaction旬痹。
本地消息表 本地消息表分布式事務解決方案是國外的eBay提出的一套方案附井。?
?需要注意的是讨越，該方案中，在A系統中永毅，我們首先寫入業(yè)務表把跨，然后寫入消息表，然后將消息發(fā)送到MQ中沼死，在B系統中需要先寫入消息表着逐，這是為了保證消息重復消費，為了保證消息消費的冪等性意蛀，我們可以使用數據的唯一鍵來約束耸别。
當B系統執(zhí)行成功之后，需要通知A系統執(zhí)行成功县钥，此時可以使用一個監(jiān)聽器秀姐，如Zookeeper，ZK監(jiān)聽到執(zhí)行成功更新A系統成功若贮。然后開始發(fā)送下一條消息省有。
A系統中需要有一個后臺線程，不斷的去判斷A系統的狀態(tài)為待確認的消息谴麦，設置超時機制蠢沿，如果超時，重新發(fā)送到MQ中匾效。直到執(zhí)行成功舷蟀。
可以看出，本地消息表方案需要寫入消息表中面哼，如果在高并發(fā)的場景下會進行大量的磁盤IO野宜，因此該方案不適用于高并發(fā)場景。
4.可靠消息最終一致性方案 該方案基于本地消息表進行優(yōu)化精绎，不使用本地消息表速缨，而是基于MQ，比如阿里的RocketMQ就支持消息事務代乃。?
?在該方案中旬牲，首先A系統需要向MQ中發(fā)送prepare消息仿粹，然后執(zhí)行A系統的業(yè)務，寫入數據庫成功之后向MQ發(fā)送confirm消息原茅，當消息為confirm狀態(tài)時吭历，B系統就可以消費到消息，消費成功之后返回ACK確認消息給MQ擂橘。
需要注意的是晌区。需要保證B系統消費消息的冪等性，可以借助第三方系統通贞。比如在redis中設置標識朗若，標明已經消費過該消息，或者借助ZK基于分布式鎖的原理昌罩，創(chuàng)建節(jié)點哭懈，重復消費消息，創(chuàng)建失敗茎用。
5.最大努力通知方案 最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務遣总，適用于一些最終一致性時間敏感度低的業(yè)務，且被動方處理結果 不影響主動方的處理結果轨功。典型的使用場景：如銀行通知旭斥、商戶通知等。?
?在該系統中古涧，A系統執(zhí)行完本地事務垂券，向MQ發(fā)送消息，最大努力通知服務消費消息蒿褂，比如消息服務圆米，然后調用B系統的接口，執(zhí)行B系統的本地事務啄栓，如果B系統執(zhí)行成功則OK娄帖，否則不斷重試，重復多次之后還是失敗的話就放棄執(zhí)行昙楚。
