目錄
(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 目前幾種流行的分散式事務技術方案對比
| 名稱 | 廠商 | 特點（優點） | 缺點 |
|---|---|---|---|
| Seata | Alibaba | 對業務無侵入、高效能 | Seata 是工作在讀未提交的隔離級別，Seata 本身存在一定的效能損耗 |
2. Seata
Seata 是一款開源的分散式事務解決方案，致力於在微服務架構下提供高效能和簡單易用的分散式事務服務；它提供了 AT、TCC、Saga 和 XA 事務模式，為開發者提供了一站式的分散式事務解決方案；
最後
新人制作，如有錯誤，歡迎指出，感激不盡！
歡迎關注公眾號，會分享一些更日常的東西！
如需轉載，請標註出處！
