分布式事務的話主要有兩種方式：

（1）兩階段提交協議。就是在兩個不同服務的上層有一個事務協調器（TC）。當發起一個請求時，TC先將消息寫到本地日志里，之后向所有服務發起消息，本地日志是為例故障后恢復所用，相當于憑證的效果。所有服務收到消息后，執行具體本機事務，但不會進行commit,如果成功返回yes,失敗返回no。同理，返回前都應把返回的消息寫到日志里，當作憑證。TC手機所有返回的消息，如果所有服務都返回yes,那么給所有服務發送commit消息，如果有一個服務返回no,那么給所有服務發送abort消息，所有服務執行rollback。

兩階段提交性能太差，不適合高并發的系統。因為涉及到多節點間的網絡通信，通信時間長；并且事務時間相對于邊長了，鎖定的資源的時間也邊長了，造成資源等待時間也增加好多。所以，往往會使用下面這種方式來解決分布式事務。

（2）使用消息隊列來避免分布式事務。拿支付寶向余額寶轉賬的例子來說。當支付寶在扣款事務提交之前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據不真正發送，只有消息發送成功后才會提交事務。當支付寶扣款事務被提交成功后，向實時消息服務確認發送。只有在得到確認發送指令后，實時消息服務才真正發送該消息。當支付寶扣款事務提交失敗回滾后，向實時消息服務取消發送。在得到取消發送指令后，該消息將不會被發送。對應那些未確認的消息或者取消的消息，需要有一個消息狀態確認系統定時去支付寶服務區查詢這個消息的狀態并進行更新，這樣做是為了支付寶扣款事務被成功提交后，系統掛了，此時消息狀態并未被更新為“確認發送”，從而導致消息不能被發送。

使用消息隊列來避免分布式事務的優點是消息數據獨立存儲，降低業務系統與消息系統間的耦合。缺點是一次消息發送需要兩次請求，業務處理服務需要實現消息狀態會查接口。