分布式事務簡介：

事務: 指作為單個邏輯工作單元執行的一系列操作，要么完全地執行，要么完全地不執行.
本地事務: ?SqlSessionfactory? ?--》?一個數據庫范圍類事務管理.
分布式事務: 跨了多個數據庫事務管理,在微服務架構每個服務都有自己數據庫,在微服務架構中必然要用到分布式事務.

為什么需要分布式事務？

微服務應用相較于單體應用有以下不足:
①單體應用拆分為分布式系統后，進程間的通訊機制和故障處理措施變的更加復雜。
? ? ? 隨著RPC框架的成熟，第一個問題已經逐漸得到解決。例如dubbo可以支持多種通訊協議，springcloud可以非常好的支持restful調用
②系統微服務化后，一個看似簡單的功能，內部可能需要調用多個服務并操作多個數據庫實現，服務調用的分布式事務問題變的非常突出。
? ? ? 對于第二個問題，現在還沒有通用方案很好的解決微服務產生的事務問題。分布式事務已經成為微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。
③微服務數量眾多，其測試、部署、監控等都變的更加困難。
? ? ? 對于第三個問題，隨著docker、devops技術的發展以及各公有云paas平臺自動化運維工具的推出，微服務的測試、部署與運維會變得越來越容易。

柔性事務 vs 剛性事務

剛性事務是指嚴格遵循ACID原則的事務, 例如單機環境下的數據庫事務.
柔性事務是指遵循BASE理論的事務, 通常用在分布式環境中, 常見的實現方式有:
? ? ?①兩階段提交(2PC)
? ? ?②TCC補償型提交
? ? ?③基于消息的異步確保型
? ? ?④最大努力通知型

CAP

Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容忍性) 可靠性

?

定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。

BASE

跨數據庫兩段提交事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支持2PC。因為2PC是反模式，盡量不要使用2PC，使用BASE來回避。
BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：
Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)
Soft state軟狀態 狀態可以有一段時間不同步，異步。
Eventually consistent最終一致，最終數據是一致的就可以了，而不是時時高一致。
BASE思想的主要實現有
? 1.按功能劃分數據庫
? 2.sharding碎片

微服務事務方案

1.基于XA協議的兩階段提交方案：

兩階段提交(Two Phase Commit, 2PC), 具有強一致性, 是CP系統的一種典型實現.常見的標準是XA, JTA等.
? 第一階段是表決階段，所有參與者都將本事務能否成功的信息反饋發給協調者；
? 第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾

?

缺點：
? ? ? 兩階段提交中的第二階段, 協調者需要等待所有參與者發出yes請求, 或者一個參與者發出no請求后, 才能執行提交或者中斷操作. 這會造成長時間同時鎖住多個資源, 造成性能瓶頸, 如果參與者有一個耗時長的操作, 性能損耗會更明顯.
? ? ? 實現復雜, 不利于系統的擴展, 不推薦.

2.TCC (Try-Confirm-Cancle)：

TCC, 是基于補償型事務的AP系統的一種實現, 具有強一致性

?

? ? ? TCC能夠對分布式事務中的各個資源進行分別鎖定, 分別提交與釋放, 例如, 假設有AB兩個操作, 假設A操作耗時短, 那么A就能較快的完成自身的try-confirm-cancel流程, 釋放資源. 無需等待B操作. 如果事后出現問題, 追加執行補償性事務即可.
TCC是綁定在各個子業務上的(除了cancle中的全局回滾操作), 也就是各服務之間可以在一定程度上”異步并行”執行.
缺點：
? ? ?對應用的侵入性強。業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。
? ? ?實現難度較大。需要按照網絡狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel接口必須實現冪等
注意：
????事務管理器(協調器)這個節點必須以帶同步復制語義的高可用集群(HAC)方式部署.
事務管理器(協調器)還需要使用多數派算法來避免集群發生腦裂問題.
使用場景:
? ? ? 嚴格一致性
? ? ? 執行時間短
? ? ? 實時性要求高
舉例: 紅包, 收付款業務.

3.異步確保性：

通過將一系列同步的事務操作變為基于消息執行的異步操作, 避免了分布式事務中的同步阻塞操作的影響.?最終一致性,中間有可能不一致

?

執行步驟如下:

MQ發送方發送遠程事務消息到MQ Server;
MQ Server給予響應, 表明事務消息已成功到達MQ Server.
MQ發送方Commit本地事務.
若本地事務Commit成功, 則通知MQ Server允許對應事務消息被消費; 若本地事務失敗, 則通知MQ Server對應事務消息應被丟棄.
若MQ發送方超時未對MQ Server作出本地事務執行狀態的反饋, 那么需要MQ Servfer向MQ發送方主動回查事務狀態, 以決定事務消息是否能被消費.
當得知本地事務執行成功時, MQ Server允許MQ訂閱方消費本條事務消息.
需要額外說明的一點, 就是事務消息投遞到MQ訂閱方后, 并不一定能夠成功執行. 需要MQ訂閱方主動給予消費反饋(ack)

如果MQ訂閱方執行遠程事務成功, 則給予消費成功的ack, 那么MQ Server可以安全將事務消息移除;
如果執行失敗, MQ Server需要對消息重新投遞, 直至消費成功.
注意事項：
? ? ? 消息中間件在系統中扮演一個重要的角色, 所有的事務消息都需要通過它來傳達, 所以消息中間件也需要支持 HAC 來確保事務消息不丟失.
? ? ?根據業務邏輯的具體實現不同，還可能需要對消息中間件增加消息不重復, 不亂序等其它要求.

執行周期較長、實時性要求不高

例如:
? ? ? 1>跨行轉賬/匯款業務(兩個服務分別在不同的銀行中)
? ? ? 2>退貨/退款業務?
? ? ? 3>財務, 賬單統計業務(先發送到消息中間件, 然后進行批量記賬)

優秀實踐

1.如果業務場景需要強一致性, 那么盡量避免將它們放在不同服務中, 也就是盡量使用本地事務(ACID), 避免使用強一致性的分布式事務.

2.如果業務場景能夠接受最終一致性,?那么最好是使用基于消息的最終一致性的方案(異步確保型)來解決.

3.如果業務場景需要強一致性, 并且只能夠進行分布式服務部署, 那么最好是使用TCC方案而不是2PC方案來解決.

分布式事務常見框架選擇：

1.tcc-transaction

tcc-transaction是開源的TCC補償性分布式事務框架，Git地址：https://github.com/changmingxie/tcc-transaction
TCC為Try、Confirm、Cancel的縮寫：try階段預留資源嘗試提交，confirm階段確定提交，cancel取消提交釋放資源。
1.2.x項目指南地址：https://github.com/changmingxie/tcc-transaction/wiki/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%971.2.x
侵入性高

???????2.tx-lcn

介紹："LCN并不生產事務，LCN只是本地事務的協調者"
? ? LCN分布式事務框架的核心功能是對本地事務的協調控制，框架本身并不創建事務，只是對本地事務做協調控制。因此該框架與其他第三方的框架兼容性強，支持所有的關系型數據庫事務，支持多數據源，支持與第三方數據庫框架一塊使用（例如 sharding-jdbc），在使用框架的時候只需要添加分布式事務的注解即可，對業務的侵入性低。LCN框架主要是為微服務框架提供分布式事務的支持，在微服務框架上做了進一步的事務機制優化，在一些負載場景上LCN事務機制要比本地事務機制的性能更好，4.0以后框架開方了插件機制可以讓更多的第三方框架支持進來。
特點：
? ?①支持各種基于spring的db框架
? ?②兼容SpringCloud、Dubbo、motan
? ?③使用簡單，低依賴，代碼完全開源
? ?④基于切面的強一致性事務框架
? ?⑤高可用，模塊可以依賴RPC模塊做集群化，TxManager也可以做集群化
? ?⑥支持本地事務和分布式事務共存
? ?⑦支持事務補償機制，增加事務補償決策提醒
? ?⑧添加插件拓展機制

3.???????GTS–分布式事務解決方案

GTS是一款分布式事務中間件，由阿里巴巴中間件部門研發，可以為微服務架構中的分布式事務提供一站式解決方案。
GTS的核心優勢：
性能超強
GTS通過大量創新，解決了事務ACID特性與高性能、高可用、低侵入不可兼得的問題。單事務分支的平均響應時間在2ms左右，3臺服務器組成的集群可以支撐3萬TPS以上的分布式事務請求。
應用侵入性極低
GTS對業務低侵入，業務代碼最少只需要添加一行注解（@TxcTransaction）聲明事務即可。業務與事務分離，將微服務從事務中解放出來，微服務關注于業務本身，不再需要考慮反向接口、冪等、回滾策略等復雜問題，極大降低了微服務開發的難度與工作量。
完整解決方案
GTS支持多種主流的服務框架，包括EDAS，Dubbo，Spring Cloud等。 ?
有些情況下，應用需要調用第三方系統的接口，而第三方系統沒有接入GTS。此時需要用到GTS的MT模式。GTS的MT模式可以等價于TCC模式，用戶可以根據自身業務需求自定義每個事務階段的具體行為。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
容錯能力強
GTS解決了XA事務協調器單點問題，實現真正的高可用，可以保證各種異常情況下的嚴格數據一致。
但是不開源！！

???????選擇

?GTS比較NB但是不開源，所以選擇tx-lcn

LCN分布式事務框架入門 可看我的另外一篇文章：?https://blog.csdn.net/qq_38225558/article/details/86133637

轉載于:https://www.cnblogs.com/powerwu/articles/11276389.html

總結

以上是生活随笔為你收集整理的SpringCloud入门 - 分布式事务【概念、常见框架选择 - tx-lcn】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。