目錄
前言
參考資料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服務原理與實戰》
《B站 尚硅谷 SpringCloud 框架開發教程 周陽》
分布式事務是指事務的參與者、支持事務的服務器、資源服務器及事務管理器分別位於分布式系統的不同節點上；
1. 基礎知識
1.1 分布式事務問題的理論模型
1.1.1 X/Open 分布式事務模型（XA 協議）
- X/Open DTP 包含以下三種角色：
- AP：Application，表示應用程序；
- RM：Resource Manager，表示資源管理器，比如數據庫；
- TM：Transaction Manager，表示事務管理器，一般指事務協調者，負責協調和管理事務，提供 AP 編程接口或管理 RM 。可以理解為 Spring 中提供的 Transaction Manager；
-TM 和多個 RM 之間的事務控制，是基於 XA 協議（XASpecification）來完成的。XA 協議是 X/Open 提出的分布式事務處理規范，也是分布式事務處理的工業標准，它定義了 xa_ 和 ax_ 系列的函數原型及功能描述、約束等。目前 Oracle、MySQL、DB2 都實現了 XA 接口，所以它們都可以作為 RM；
1.1.2 兩階段提交協議
-
兩階段：
- 事務的准備階段：事務管理器（TM）通知資源管理器（RM）准備分支事務，記錄事務日志，並告知事務管理器的准備結果；
- 事務的提交或者回滾階段：如果所有的資源管理器（RM）在准備階段都明確返回成功，則事務管理器（TM）向所有的資源管理器（RM）發起事務提交指令完成數據的變更。反之，如果任何一個資源管理器（RM）明確返回失敗，則事務管理器（TM）會向所有資源管理器（RM）發送事務回滾指令；
-
優點：簡單，降低事務提交失敗率；
-
缺點：同步阻塞（對於任何一次指令都必須要有明確的響應才能繼續進行下一步）、過於保守（任何一個節點失敗都會導致數據回滾）；
1.1.3 三階段提交協議
- 三階段：
- CanCommit（詢問階段）：事務協調者向參與者發送事務執行請求，詢問是否可以完成指令，參與者只需要回答是或者不是即可，不需要做真正的事務操作，這個階段會有超時中止機制；
- PreCommit（准備階段）：事務協調者會根據參與者的反饋結果決定是否繼續執行，如果在詢問階段所有參與者都返回可以執行操作，則事務協調者會向所有參與者發送 PreCommit 請求，參與者收到請求后寫 redo 和 undo 日志，執行事務操作但是不提交事務，然后返回 ACK 響應等待事務協調者的下一步通知。如果在詢問階段任意參與者返回不能執行操作的結果，那么事務協調者會向所有參與者發送事務中斷請求；
- DoCommit（提交或回滾階段）：這個階段也會存在兩種結果，仍然根據上一步驟的執行結果來決定 DoCommit 的執行方式。如果每個參與者在 PreCommit 階段都返回成功，那么事務協調者會向所有參與者發起事務提交指令。反之，如果參與者中的任一參與者返回失敗，那么事務協調者就會發起中止指令來回滾事務；
- 優點：可以盡早發現無法執行操作而中止后續的行為；在准備階段后，事務協調者和參與者都引入了超時機制；基於超時機制來避免資源的永久鎖定；
- 缺點：一旦超時，仍然可能出現數據不一致的情況；
1.2 分布式事務的兩個理論模型
1.2.1 CAP 定理
- 與《微服務架構 | 3. 注冊中心與服務發現》中講解的一樣，指在分布式系統中不可能同時滿足一致性（C:Consistency）、可用性（A:Availability）、分區容錯性（P:Partition Tolerance）這三個基本需求，最多同時滿足兩個；
- C：數據在多個副本中要保持強一致，比如前面說的分布式數據一致性問題；
- A：系統對外提供的服務必須一直處於可用狀態，在任何故障下，客戶端都能在合理的時間內獲得服務端的非錯誤響應；
- P：在分布式系統中遇到任何網絡分區故障，系統仍然能夠正常對外提供服務；
- 網絡分區：不同節點分布在不同的子網絡中時，在內部子網絡正常的情況下，由於某些原因導致這些子節點之間出現網絡不通的情況，導致整個系統環境被切分成若干獨立的區域，這就是網絡分區；
- 在分布式系統中，不會選擇 CA，而是 AP 和 CP；
- AP：放棄了強一致性，實現最終的一致，是很多互聯網公司解決分布式數據一致性問題的主要選擇；
- CP：放棄了高可用性，實現強一致性。前面提到的兩階段提交和三階段提交都采用這種方案。可能導致的問題是用戶完成一個操作會等待較長的時間；
- CA：無法同時做到保證數據一致性和可用，要保證數據一致性可能要拒絕客戶端請求，除非網絡百分百可靠；
1.2.2 BASE 理論
- BASE 理論是由於 CAP 中一致性 C 和可用性 A不可兼得而衍生出來的一種新的思想，BASE 理論的核心思想是通過犧牲數據的強一致性來獲得高可用性。它有如下三個特性；
- Basically Available（基本可用）：分布式系統在出現故障時，允許損失一部分功能的可用性，保證核心功能的可用；
- Soft State（軟狀態）：允許系統中的數據存在中間狀態，這個狀態不影響系統的可用性，也就是允許系統中不同節點的數據副本之間的同步存在延時；
- Eventually Consistent（最終一致性）：中間狀態的數據在經過一段時間之后，會達到一個最終的數據一致性；
- BASE 理論並沒有要求數據的強一致，而是允許數據在一段時間內是不一致的，但是數據最終會在某個時間點實現一致；
- 在互聯網產品中，大部分都會采用 BASE 理論來實現數據的一致，因為產品的可用性對於用戶來說更加重要；
- 舉個例子，在電商平台中用戶發起一個訂單的支付，不需要同步等待支付的執行結果，系統會返回一個支付處理中的狀態到用戶界面。對於用戶來說，他可以從訂單列表中看到支付的處理結果。而對於系統來說，當第三方的支付處理成功之后，再更新該訂單的支付狀態即可。在這個場景中，雖然訂單的支付狀態和第三方的支付狀態存在短期的不一致，但是用戶卻獲得了更好的產品體驗；
1.3 分布式事務問題的常見解決方案（事務模式）
在互聯網場景中更多采用柔性事務，所謂的柔性事務是遵循 BASE 理論來實現的事務模型，它有兩個特性：基本可用、柔性狀態；
1.3.1 TCC 補償型方案
- TCC（Try-Confirm-Cancel）是一種比較成熟的分布式數據一致性解決方案，它實際上是把一個完整的業務拆分為如下三個步驟：
- Try：這個階段主要是對數據的校驗或者資源的預留（凍結資源）；
- Confirm：確認真正執行的任務，只操作 Try 階段預留的資源（消耗凍結資源）；
- Cancel：取消執行，釋放 Try 階段預留的資源（解凍資源）；
- 其實 TCC 是一種兩階段提交的思想，第一階段通過 Try 進行准備工作，第二階段 Confirm/Cancel 表示 Try 階段操作的確認和回滾；
- 在一些特殊情況下，服務並沒有收到 TCC 事務協調器的 Cancel 或者 Confirm 請求時，可以記錄一些分布式事務的操作日志，保存分布式事務運行各個階段和狀態，以實現一致性；
- TCC 服務支持接口調用失敗發起重試，所以 TCC 暴露的接口都需要滿足冪等性；
1.3.2 基於可靠性消息的最終一致性方案
- 基於可靠性消息的最終一致性是互聯網公司比較常用的分布式數據一致性解決方案；
- 它主要利用消息中間件（Kafka、RocketMQ 或 RabbitMQ）的可靠性機制來實現數據一致性的投遞；
- 在某些場景中可以犧牲數據的一致性在短時間內不要求實時性，所以可以采用基於可靠性消息的最終一致性方案來保證最終的數據一致性；
- 在消費者沒有向消息中間件服務器發送確認時，這個消息會被重復投遞，確保消息的可靠性消費；
- RocketMQ 使用事件消息模型解決事務問題，其核心是事務回查，主要邏輯如下：
- 生產者發送一個事務消息到消息隊列上，消息隊列只記錄這條消息的數據，此時消費者無法消費這條消息；
- 生產者執行具體的業務邏輯，完成本地事務的操作；
- 接着生產者根據本地事務的執行結果發送一條確認消息給消息隊列服務器，如果本地事務執行成功，則發送一個 Commit 消息，表示在第一步中發送的消息可以被消費，否則，消息隊列服務器會把第一步存儲的消息刪除；
- 如果生產者在執行本地事務的過程中因為某些情況一直未給消息隊列服務器發送確認，那么消息隊列服務器會定時主動回查生產者獲取本地事務的執行結果，然后根據回查結果來決定這條消息是否需要投遞給消費者；
- 消息隊列服務器上存儲的消息被生產者確認之后，消費者就可以消費這條消息，消息消費完成之后發送一個確認標識給消息隊列服務器，表示該消息投遞成功；
1.3.3 最大努力通知型
- 與基於可靠性消息的最終一致性方案類似，適用於對數據一致性要求不高的場景；
- 在支付服務沒有返回一個消息確認時，支付寶會不斷進行重試，直到一個消息確認或達到最大重試次數；
1.3.4 AT 模式
- AT 模式是 Seata 最主推的分布式事務解決方案，它是基於 XA 演進而來的一種分布式事務模式。分為三大模塊：TM、RM 和 TC（與XA不同）。其中：
- TM 事務管理器：負責向 TC 注冊一個全局事務，並生成一個全局唯一的 XID。作為 Seata 的客戶端與業務系統集成；
- RM 數據庫資源：在業務層面通過 JDBC 標准的接口訪問 RM 時， Seata 會對所有請求進行攔截。作為 Seata 的客戶端與業務系統集成；
- TC 事務協調器：每個本地事務進行提交時，RM 都會向 TC 注冊一個分支事務。作為 Seata 的服務器獨立部署；
- AT 模式和 XA 一樣，也是一個兩階提交事務模型；
1.3.5 Saga 模式
- Saga 模式又稱為長事務解決方案，主要描述的是在沒有兩階段提交的情況下如何解決分布式事務問題；
- 其核心思想是：把一個業務流程中的長事務拆分為多個本地短事務，業務流程中的每個參與者都提交真實的提交給該本地短事務，當其中一個參與者事務執行失敗，則通過補償機制補償前面已經成功的參與者；
- Saga 的機制相關詳情請見筆者的另一篇文章：《微服務架構設計模式》讀書筆記 | 第4章 使用Saga管理事務；
1.5 目前幾種流行的分布式事務技術方案對比
| 名稱 | 廠商 | 特點（優點） | 缺點 |
|---|---|---|---|
| Seata | Alibaba | 對業務無侵入、高性能 | Seata 是工作在讀未提交的隔離級別，Seata 本身存在一定的性能損耗 |
2. Seata
Seata 是一款開源的分布式事務解決方案，致力於在微服務架構下提供高性能和簡單易用的分布式事務服務；它提供了 AT、TCC、Saga 和 XA 事務模式，為開發者提供了一站式的分布式事務解決方案；
最后
