目前解決的辦法有基於XA的2pc兩階段提交，實際上就是整個事務過程由事務管理器和資源管理器來共同參與。這麼一說可能題主就明白了這是位於資源層面的解決方案，說白了就是你的資料庫或者MQ要支援兩階段提交協議，由於在整個事務過程中會一直鎖定資源，而且涉及到網路操作，那這個東西就不太可靠，而且會影響效能，擴充套件性和可用性都不友好，同時對於服務層面的分散式它是搞定不定的。所以後面又搞出來個tcc，這個類似2pc，只是它是位於業務層面，基本的思路是把比較長的分散式事務拆分成本地的短事務。這需要結合業務的特點去設計，比如買10塊錢的東西，針對支付這個服務，在進行扣費的時候先有個凍結使用者10塊錢的動作，這個就是try。等到後面tcc框架發起confirm操作時才真正把10塊錢扣掉，如果tcc框架發起cancel操作則把10塊錢解凍。需要注意的是由於confirm和cancel可能失敗，因此可以結合全域性事務ID設計成冪等性的介面。

上面兩種從某種程度上來講都能提供比較強的一致性，但是有很多場景是不需要這種強一致性的。根據CAP（一致性、可用性、可靠性）的理論，魚和熊掌不可兼得，可靠性是必須要的，所以需要在C和A之間做平衡，實際上在網際網路領域Ａ也是必須的，因此就不得不在Ｃ上做文章。於是有了弱一致或者最終一致，它不要求你在做完一個操作後能立馬看到效果，只要在可接受的時間內看到正確的結果即可。這方面的內容epay的架構師有過介紹，目前業界用這種的比較多，Sina Visitor System 這篇文章講解的比較詳細。其解決分散式事務的思路就是避免分散式事務，具體來說就是利用本地事務+非同步訊息+重試+冪等去保證整個系統資料的最終一致性。