分散式事務簡介：

事務: 指作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行.
本地事務:  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.非同步確保性：

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

執行步驟如下:

1. MQ傳送方傳送遠端事務訊息到MQ Server;
2. MQ Server給予響應, 表明事務訊息已成功到達MQ Server.
3. MQ傳送方Commit本地事務.
4. 若本地事務Commit成功, 則通知MQ Server允許對應事務訊息被消費; 若本地事務失敗, 則通知MQ Server對應事務訊息應被丟棄.
5. 若MQ傳送方超時未對MQ Server作出本地事務執行狀態的反饋, 那麼需要MQ Servfer向MQ傳送方主動回查事務狀態, 以決定事務訊息是否能被消費.
6. 當得知本地事務執行成功時, 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