什么是分布式事物
分布式系統中保證不同節點之間的數據一致性的事物，叫做分布式事物。
為什么要用分布式事物
微服務，SOA等服務架構模式，一個是service產生多個節點，另一個是resource產生多個節點。
service多個節點
resource多個節點
系統故障、網絡錯誤等情況下，都會導致數據存儲不一致的情況，這種情況就需要分布式事物來處理。
如何用分布式事物
分布式事物解決方案
XA二階段提交
1.性能問題
XA協議遵循強一致性。在事務執行過程中，各個節點占用着數據庫資源，只有當所有節點准備完畢，事務協調者才會通知提交，參與者提交后釋放資源。這樣的過程有着非常明顯的性能問題。
2.協調者單點故障問題
事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處於中間狀態無法完成事務。
3.丟失消息導致的不一致問題。
在XA協議的第二個階段，如果發生局部網絡問題，一部分事務參與者收到了提交消息，另一部分事務參與者沒收到提交消息，那么就導致了節點之間數據的不一致。
XA三階段提交
XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事物參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。
MQ事務
利用消息中間件來異步完成事務的后一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的性能問題。不過由於會出現網絡延遲的問題，消息重復、消息順序無法保證的情況也會出現。需要業務機制進行補償。
本地消息表
將需要分布式處理的任務通過消息日志的方式來異步執行。消息日志可以存儲到本地文本、數據庫或消息隊列，再通過業務規則自動或人工發起重試。人工重試更多的是應用於支付場景，通過對賬系統對事后問題的處理。
Saga事務
將長事務拆分為多個本地短事務，由Saga事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次調用補償操作。saga模式沒有隔離性的影響還是較大。
LCN事務
LCN模式是通過代理Connection的方式實現對本地事務的操作，然后在由TxManager統一協調控制事務。當本地事務提交回滾或者關閉連接時將會執行假操作，該代理的連接將由LCN連接池管理。
該模式對代碼的嵌入性為低。
該模式僅限於本地存在連接對象且可通過連接對象控制事務的模塊。
該模式下的事務提交與回滾是由本地事務方控制，對於數據一致性上有較高的保障。
該模式缺陷在於代理的連接需要隨事務發起方一共釋放連接，增加了連接占用的時間
Atomikos事務
優點：
缺點：
1. Atomikos從池里取得connection時，每次都會去進行select test，這個對獲取連接的影響很大，取消這個測試，TPS大概能提高近1倍；
2. Atomilos對池中connection的管理效率隨着連接數的上升，呈現指數級的下降，測試環境中，連接最大配置為300，但實際上最大值沒有超過70，線程dump發現連接池管理對象上存在激烈的鎖競爭，導致很多線程等待前面的線程釋放鎖對象；
3. 由於Atomikos支持JTA事務，而c3p0則不支持，這導致atomikos在獲取connection時，首先需要從線程上下文去檢索是否已經存在着connection，這個檢測從atomikos的實現上看，會遍歷連接池中所有connection對象，所以當連接數上升時，連接池的效率顯著下降；
TCC事務
TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似於XA兩階段提交，但是實現方式是在代碼層面來人為實現。
該模式對代碼的嵌入性高，要求每個業務需要寫三種步驟的操作。
該模式對有無本地事務控制都可以支持使用面廣。
數據一致性控制幾乎完全由開發者控制，對業務開發難度要求高。
TCC事務機制相比於上面介紹的XA，解決了其幾個缺點:
1.解決了協調者單點，由主業務方發起並完成這個業務活動。業務活動管理器也變成多點，引入集群。
2.同步阻塞:引入超時，超時后進行補償，並且不會鎖定整個資源，將資源轉換為業務邏輯形式，粒度變小。
3.數據一致性，有了補償機制之后，由業務活動管理器控制一致性 。
TCC事務的缺點，主要就一個：
- TCC的Try、Confirm和Cancel操作功能需業務提供，開發成本高。
到底要不要使用TCC到底要不要使用TCC事務，取決於以下幾點：
- 是否真正有保證跨應用業務操作的原子性需求。
- 研發上能否投入資源開發相對應的TCC接口。
- 當然還有最后一點，能否搞定一個穩定的、高可用的、擴展性強的TCC事務管理器。
Fescar
優點
高效 並且對業務 0 侵入 的方式，解決 微服務 場景下面臨的分布式事務問題。
缺點
存在一些局限，比如：事務隔離級別最高支持到 讀已提交 的水平，SQL 的解析還不能涵蓋全部的語法等。
分為AT模式和MT模式，默認的是AT模式，但是最好是AT模式和MT模式結合使用，因為MT模式可以將非關系型數據庫也納入全局事務管理中。
AT模式的行為分支
業務邏輯不需要關注事務機制，分支與全局事務的交互過程自動進行。
MT模式的行為分支
業務邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全局事務。
MT 模式一方面是 AT 模式的補充。另外，更重要的價值在於，通過 MT 模式可以把眾多非事務性資源納入全局事務的管理中。
詳細了解網址https://blog.csdn.net/qq924862077/article/details/86556559
參考網址：
https://blog.csdn.net/bjweimengshu/article/details/79607522
https://www.cnblogs.com/bigben0123/p/9453830.html
https://blog.csdn.net/jl19861101/article/details/54864019