Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分佈式事物的比較

什麼是分佈式事物

分佈式系統中保證不一樣節點之間的數據一致性的事物，叫作分佈式事物。

爲何要用分佈式事物

微服務，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.   全面崩潰 / 重啓恢復

2.  兼容標準的SUN公司JTA API

3.  嵌套事務

4.  爲XA和非XA提供內置的JDBC適配器

缺點：

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