1、什么是分布式事務

分布式事務就是指事務的資源分別位于不同的分布式系統的不同節點之上的事務；

2、分布式事務產生的原因

2.1、數據庫分庫分表

在單庫單表場景下，當業務數據量達到單庫單表的極限時，就需要考慮分庫分表，將之前的單庫單表拆分成多庫多表；

分庫分表之后，原來在單個數據庫上的事務操作，可能就變成跨多個數據庫的操作，此時就需要使用分布式事務；

2.2、業務服務化

業務服務化即業務按照面向服務（SOA）的架構拆分整個網站系統；

比如互聯網金融網站SOA拆分，分離出交易系統、賬務系統、清算系統等，交易系統負責交易管理和記錄交易明細，賬務系統負責維護用戶余額，所有的業務操作都以服務的方式對外發布；

一筆金融交易操作需要同時記錄交易明細和完成用戶余額的轉賬，此時需要分別調用交易系統的交易明細服務和賬務系統的用戶余額服務，這種跨應用、跨服務的操作需要使用分布式事務才能保證金融數據的一致性；

3、分布式事務原理簡介

3.1、ACID

1、原子性（Atomicity）

整個事務中的所有操作，要么都成功，要么都失敗，不可能部分操作成功部分操作失敗；

2、一致性（Consistency）

事務必須使數據庫的數據從一個一致性狀態變換到另外一個一致性狀態。

3、隔離性（Isolation）

事務的隔離性是指一個事務的執行不能被其他事務干擾，即一個事務內部的操作及使用的數據對并發的其他事務是隔離的，并發執行的各個事務之間不能互相干擾。

4、持久性（Durability）

在事務成功以后，該事務對數據庫所做的更改應當持久的保存在數據庫中；

3.2、2PC

兩階段提交協議（Two Phase Commitment Protocol）是分布式事務的基礎協議。

在此協議中，一個事務協調器（TM, transaction manager）協調多個資源管理器（RM, resource manager）的活動；在一階段所有資源管理器（RM）向事務管理器（TM）匯報自身活動狀態，在第二階段事務管理器（TM）根據各資源管理器（RM）匯報的狀態，來決定各RM是執行提交操作還是回滾操作；具體描述如下：

1) 應用程序向事務管理器（TM）提交請求，發起方分布式事務；

2) 一階段，事務管理器（TM）聯絡所有資源管理器（RM），通知它們執行準備操作；

3) 資源管理器（RM）返回準備成功，或者失敗的消息給TM（響應超時算作失敗）；

4) 二階段，如果所有RM均準備成功，TM會通知所有RM執行提交；如果任一RM準備失敗，TM會通知所有RM回滾；

通過事務管理器2階段協調資源管理器，使所有資源管理器的狀態最終都是一致的，要么全部提交，要么全部回滾。

3.3、2PC應用之XA

XA是X/Open組織提出的，定義了事務管理器與資源管理器之間通信的接口協議；XA協議由數據庫實現，目前支持XA協議的數據庫有Oracle、MySql、BD2等；

XA定義了一系列的接口：

• xa_start: 啟動XA事務
• xa_end: 結束XA事務
• xa_prepare: 準備階段，XA事務預提交
• xa_commit： 提交XA事務
• xa_rollback: 回滾XA事務

一個數據庫實現XA協議之后，它就可以作為作為一個資源管理器參與到分布式事務中;

在一階段，事務管理器協調所有數據庫執行XA事務（xa_start、用戶SQL、xa_end），并完成XA事務預提交（xa_prepare）；

在二階段，如果所有數據庫上XA事務預提交均成功，那么事務管理器協調所有數據庫提交XA事務（xa_commit）；如果任一數據庫上XA是我預提交失敗，那么事務管理器會協調所有數據組回滾XA事務（xa_rollback）;

3.4、2PC應用之TCC

TCC是Try、Confirm、Cancel 3個操作的縮寫；

Try操作對應2PC的一階段Prepare，Confirm對應2PC的二階段commit，Cancel對應2PC的二階段rollback；

這3個操作均有用戶編碼實現；

TCC三個操作描述：

• Try: 檢測、預留資源;
• Confirm: 業務系統執行提交；默認Confirm階段是不會出錯的，只要TRY成功，CONFIRM一定成功；
• Cancel: 業務取消，預留資源釋放;

用戶通編碼實現TCC并發布成服務，這個TCC服務就可以作為資源參與到分布式事務中；事務管理器分2階段協調所有的TCC資源，使得所有TCC資源狀態最終都是一致，要么全部提交，要么全部回滾；

TCC自編碼的特性決定TCC資源管理器可以跨DB、跨應用實現資源管理，將對不同的DB訪問、不同的業務操作通過編碼方式轉換一個原子操作，解決了復雜業務場景下的事務問題；

同時TCC的每一個操作對于DB來講都是一個本地DB事務，操作結束則本地DB事務結束，數據庫的資源也就被釋放；這就規避了數據庫層面的2PC對資源占用導致的性能低下問題；

3.5、柔性事務

單數據庫事務完全遵循ACID規范，屬于剛性事務，分布式事務要完全遵循ACID規范比較困難, 分布式事務屬于柔性事務，滿足BASE理論；

BASE描述：?BA（Basic Availability 基本業務可用性）、S（Soft state 柔性狀態）、E（Eventual consistency 最終一致性）；

柔性事務對ACID的支持：

1、原子性：

嚴格遵循；

2、一致性：

事務完成后的一致性嚴格遵循，事務中的一致性可適當放寬；

3、隔離性：

并行事務間不可影響；事務中間結果可見性允許安全放寬；

4、持久性：

嚴格遵循；

為了可用性、性能的需要，柔性事務降低了一致性(C)與隔離性(I) 的要求，即“基本可用，最終一致”；

3.6、柔性事務的分類

柔性事務分為：兩階段型、補償型、異步確保型、最大努力通知型；

1、兩階段型

就是分布式事務兩階段提交，對應技術上的XA、JTA/JTS，這是分布式環境下事務處理的典型模式。

2、補償型

TCC型事務（Try/Confirm/Cancel）可以歸為補償型；TCC思路是:盡早釋放鎖；在Try成功的情況下，如果事務要回滾，Cancel將作為一個補償機制，回滾Try操作；

TCC各操作事務本地化，且盡早提交 (放棄兩階段約束)；當全局事務要求回滾時，通過另一個本地事務實現“補償”行為；

TCC是將資源層的兩階段提交協議轉換到業務層，成為業務模型中的一部分；

3、異步確保型

將一些同步阻塞的事務操作變為異步的操作，避免對數據庫事務的爭用；比如消息事務機制；

4、最大努力通知型

通過通知服務器(消息通知)進行，允許失敗，有補充機制；

from:?https://yq.aliyun.com/articles/608863?

總結

以上是生活随笔為你收集整理的分布式事务：分布式事务原理概述的全部內容，希望文章能夠幫你解決所遇到的問題。

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