目錄

• 前言
• 1. 基礎知識
  • 1.1 分布式事務問題的理論模型
    • 1.1.1 X/Open 分布式事務模型（XA 協議）
    • 1.1.2 兩階段提交協議
    • 1.1.3 三階段提交協議
  • 1.2 分布式事務的兩個理論模型
    • 1.2.1 CAP 定理
    • 1.2.2 BASE 理論
  • 1.3 分布式事務問題的常見解決方案（事務模式）
    • 1.3.1 TCC 補償型方案
    • 1.3.2 基于可靠性訊息的最終一致性方案
    • 1.3.3 最大努力通知型
    • 1.3.4 AT 模式
    • 1.3.5 Saga 模式
  • 1.5 目前幾種流行的分布式事務技術方案對比
• 2. Seata
• 最后

(11. 分布式事務)

前言

參考資料：
《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 目前幾種流行的分布式事務技術方案對比

2. Seata

Seata 是一款開源的分布式事務解決方案，致力于在微服務架構下提供高性能和簡單易用的分布式事務服務；它提供了 AT、TCC、Saga 和 XA 事務模式，為開發者提供了一站式的分布式事務解決方案；

• 點擊訪問：微服務架構 | 11.1 整合 Seata AT 模式實作分布式事務；

最后

標籤：其他

上一篇：微服務架構 | 10.3 使用 Zipkin 可視化日志追蹤

下一篇：微服務架構 | 11.1 整合 Seata AT 模式實作分布式事務