???????說起微服務的架構，分布式事務是一道繞不開的話題。本文將從分布式事務的理論模型、分布式事務的常見解決方案、分布式事務中間件 Seata的兩個常用模式展開說說分布式事務。

?

1、分布式事務的理論模型

?
兩階段提交協議、三階段提交 ，作為 XA 協議解決分布式數據一致性問題的基本原理。
?

1.1、X/Open 分布式事務模型

?

X/Open DTP 是 X/Open 定義的一套分布式事務標準，該標準使用兩階段提交來保證分布式事務的完整性。

X/Open DTP 中包含三種角色

• ① Application（AP）：指應用程序。
• ② Resource Manager（RM）：指資源管理器，比如數據庫。
• ③ Transaction Manager（TM）：指事務管理器，事務協調者，負責協調和管理事務，提供AP編程接口或管理RM.

?

1.2、兩階段提交協議

?
兩階段提交協議的執行流程：

• ① 準備階段：TM 通知 RM 準備分支事務，記錄事務日志，并告知 TM 的準備結果。
• ② 提交/回滾階段：
  • 如果所有的 RM 在準備階段都明確返回成功，則 TM 向所有的 RM 發起事務提交指令，完成數據變更。
  • 反之，如果任何一個 RM 明確返回失敗，則 TM 會向所有 RM 發送事務回滾指令。

兩階段提交的缺點：

• ① 同步阻塞：

  • 所有參與的 RM 都是事務阻塞型，對于任何一次指令都必須有明確的響應，才能繼續進行下一步。
  • 否則會處于阻塞狀態，占用的資源一直被鎖定。

• ② 過于保守：任何一個節點失敗都會導致數據回滾。

• ③ TM 的單點故障：如果 TM 在第二階段出現故障，那其他參與的RM 會一直處于鎖定狀態。

• ④ “腦裂” 導致數據不一致問題：第二階段中 TM 向所有的 RM 發送 commit 請求后，發生局部網絡異常，導致只要一部分 RM 接收到 commit 請求，進而執行了 commit 操作。另一部分 RM 未收到 commit 請求，從而事務無法提交，導致數據不一致問題發生。

?

1.3、三階段提交協議

?

**三階段提交協議執行流程**如下：

• ① CanCommit（詢問階段）：TM 向 RM 發送事務執行請求，詢問是否可以完成指令，RM 只需要回答是或者不是即可，不需要做真正的事務操作，該階段會有超時中止機制。

• ② PreCommit（準備階段）：TM 會根據所有 RM 的反饋結果決定是否繼續執行。

  • 如果在 CanCommit 階段所有 RM 都返回可以執行操作，則 TM 會向所有 RM 發送 PreCommit 請求，所有 RM 收到請求后寫 redo 和 undo 日志，執行事務操作但不提交事務，然后返回 ACK 響應等待 TM 的下一步通知。
  • 如果在 CanCommit 階段，任意 RM 返回不能執行操作的結果，那 TM 會向所有參與者發送事務中斷請求。

• ③ DoCommit（提交或回滾階段）：該階段根據 PreCommit 階段執行的結果，來決定 DoCommit 的執行方式。

  • 如果每個 RM 在 PreCommit 階段都返回成功，那么 TM 會向所有 RM 發起事務提交指令。
  • 如果任何一個 RM 返回失敗，那么 TM 會發起中止指令來回滾事務。
    

相對于二階段提交協議，三階段提交協議利用超時機制，解決了同步阻塞問題。兩者的區別如下：

• ① 增加了 CanCommit 階段，用于詢問所有 RM 是否可以執行事務操作并響應，其目的是可以盡早發現無法執行操作而中止后續的行為。
• ② 在準備階段之后，TM 和 RM 都引入了超時機制，一旦超時TM 和 RM 會繼續提交事務，并且認為處于成功狀態，因為在超時情況下事務默認成功的可能性比較大。超時機制避免了資源的永久鎖定。
  ?

2、分布式事務常見解決方案

?

2.1、TCC補償型方案

?

TCC（Try-Confirm-Cancel）是一種兩階段提交的思想，也是一種比較成熟的分布式事務一致性解決方案。TCC 補償型方案將一個完整事務分為三個步驟：

• ① Try ：該階段主要是對數據的校驗，或者資源的預留。
• ② Confirm ：該階段確認真正執行的任務，只操作 Try 階段預留的資源。
• ③ Cancel ：該階段是取消執行，釋放 Try 階段預留的資源。

注意：在某些特殊場景下，比如服務器突然宕機，導致該服務并沒有收到 TCC 事務協調器的 Cancel 或者 Confirm 請求，這時 TCC 事務框架會記錄一些分布式事務的操作日志，保存分布式事務運行的各個階段和狀態。TCC 事務協調器會根據操作日志進行重試，以達到數據的最終一致性。

TCC 服務支持接口調用失敗發起重試，所以 TCC 暴露的接口都需要滿足冪等性。

?

2.2、基于可靠性消息的最終一致性方案

?

???????RocketMQ 事務消息模型最核心的機制，就是事務回查。下圖可以看出，在 RocketMQ 事務消息模型中，事務是由生產者完成。消息隊列的可靠性投遞機制，保證了消費者如果沒有簽收消息，消息隊列服務器會重復投遞。具體可以參考博文 《RocketMQ 順序消息和事務消息及其原理》 的 【RocketMQ 的事務消息】部分。

?

2.3、最大努力通知型方案

?

???????最大努力通知也被稱為定期校對，是以上【基于可靠性消息的最終一致性方案】的優化版，其引入了本地消息表來記錄錯誤消息，然后加入失敗消息的定期校對功能，來進一步保證消息被下游系統消費。
?

最大努力通知方案步驟：

• 第一步：消息由系統A投遞到中間件

  • ① 業務處理中，操作業務數據入庫時，在同一事務中向本地消息表中寫一條數據，且數據狀態為【未發送】。
  • ② 一般采用定時任務，輪詢本地消息表中【未發送】狀態的數據，將這部分數據發送到消息中間件。
  • ③ 消息中間件收到消息后，通過消息中間件的返回應答狀態，修改本地消息表狀態為【發送成功】。

• 第二步：消息中間件投遞到系統B

  • ① 消息中間件收到第一步的消息后，同步投遞給相應的下游系統，并觸發下游系統的業務執行。
  • ② 當下游系統業務處理成功后，向消息中間件反饋確認應答，消息中間件便可以將消息刪除，從而完成該事務。
  • ③ 對于投遞失敗的消息，利用重試機制進行重試，對于重試失敗的，寫入錯誤消息表。
  • ④ 消息中間件需要提供失敗消息的查詢接口，下游系統會定期查詢失敗消息。

最大努力通知方案缺點：消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會增加系統的復雜度。

?

3、分布式事務中間件 Seata

?

Seata 組件作為一種分布式解決方案，提供了 AT、TCC、Saga 和 XA 事務模型。

3.1、AT 模式

?
???????AT 模式是基于 XA 模式演化而來的，AT 和 XA 都是兩階段事務模型，但是 AT 和XA 相比，做了很多優化。AT 模式作為 Seata 最主推的分布式事務解決方案。

???????AT 模式由 TM、RM 和 TC 三大模塊組成，其中 TM 和 RM 作為客戶端與業務系統（Application）集成，TC 作為 Seata 的服務器獨立部署。AT 模式的執行流程：

• ① TM 向 TC 注冊全局事務，并生成全局唯一的 XID.
• ② RM 向 TC 注冊分支事務，并將其納入該 XID 對應的全局事務范圍。
• ③ RM 向 TC 匯報資源的準備狀態。
• ④ TC 匯總所有事務參與者的執行狀態，決定分布式事務是全部回滾還是提交。
• ⑤ TC 通知所有 RM 提交/回滾事務。

???????Seata的AT模式在性能、一致性模型、侵入性、依賴性和靈活性以及配置和部署等方面，相對于XA模式進行了顯著的改進。這些改進使得AT模式成為了一種更加高效、易用和靈活的分布式事務解決方案。

1. 性能提升

• 資源鎖定周期縮短：XA模式一階段不提交事務，鎖定資源直到二階段結束才釋放，這可能導致性能瓶頸。而AT模式一階段直接提交事務，不鎖定資源，從而縮短了資源鎖定周期，提高了系統性能。
• 減少數據庫交互：AT模式通過記錄數據快照（undo log）來實現回滾，減少了與數據庫的交互次數，進一步提升了性能。

2. 一致性模型

• 最終一致性 vs 強一致性：XA模式遵循兩階段提交協議，保證事務的強一致性（滿足ACID原則）。而AT模式則通過數據快照和全局鎖來實現最終一致性，雖然數據不是實時一致的，但在最終狀態上保持一致，這種模型在某些場景下可以接受，并且減少了鎖的使用，提高了性能。

3. 侵入性降低

• 代碼侵入性：XA模式通常需要業務代碼顯式地參與事務管理，如調用XA接口等。而AT模式則是一種無侵入的分布式事務解決方案，用戶只需關注自己的業務SQL，Seata框架會自動處理事務的二階段提交和回滾操作，降低了對業務代碼的侵入性。

4. 依賴性和靈活性

• 數據庫依賴性：XA模式高度依賴關系型數據庫來實現事務的強一致性。而AT模式雖然也依賴數據庫，但更多地是通過Seata框架的數據快照和全局鎖機制來實現最終一致性，因此對數據庫的依賴性和要求相對較低。
• 靈活性：AT模式提供了更高的靈活性，它支持多種數據庫類型（如MySQL、Oracle、PostgreSQL和TiDB等），并且可以根據業務需求進行靈活配置和調整。

?

3.2、Saga 模式

?

???????Saga 模式是一種長事務解決方案，其核心思想是將一個業務流程中的長事務，拆分成多個本地短事務。業務流程中的每個參與者都提交真實的提交給本地短事務，當其中一個參與者事務執行失敗，則通過補償機制補償前面已經成功的參于者。

???????Sage 由一系列 sub-transaction T i 組成，每個 T i 都有對應的補償動作 C i，補償動作用于撤銷 T i 造成的數據變更結果。每一個 T i 操作都真實的影響數據庫。
?
Sage 模式的兩種執行方式：

• T1、T2、T3、 … 、T i ：這種方式表示所有事務都正常執行。
• T1、T2、 … 、T j、C j 、… 、C2、C1（其中 0 < j < i）：這種方式表示執行到 T j 事務時出現異常，通過補充操作撤銷之前所有成功的 sub-transaction.

Sage 提供了兩種補償恢復方式：

• ① 向后恢復：如果任一子事務執行失敗，則把之前執行的結果逐一撤銷。
• ② 向前恢復：該恢復方式不進行補償，而是對失敗的事務進行重試，其比較適合于事務必須要執行成功的場景。

Saga 的優劣勢：

• 和XA 和 TCC 相比，Saga 的一階段直接提交本地事務，沒有鎖等待，性能比較高；在事件驅動的模式下，短事務可以異步執行；補償機制的實現比較簡單。
• Sage 的缺點是并不提供原子性和隔離性支持，隔離性的影響比較大。比如 業務中贈送了一張優惠券，若用戶將優惠券使用了，且事務如果出現異常要回滾就會出現問題。

?
?
?
?
?
?
?
.