前言

參考資料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服務(wù)原理與實(shí)戰(zhàn)》
《B站 尚硅谷 SpringCloud 框架開發(fā)教程 周陽》

分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器及事務(wù)管理器分別位于分布式系統(tǒng)的不同節(jié)點(diǎn)上；

1. 基礎(chǔ)知識

1.1 分布式事務(wù)問題的理論模型

1.1.1 X/Open 分布式事務(wù)模型（XA 協(xié)議）

• X/Open DTP 包含以下三種角色：
  • AP：Application，表示應(yīng)用程序；
  • RM：Resource Manager，表示資源管理器，比如數(shù)據(jù)庫；
  • TM：Transaction Manager，表示事務(wù)管理器，一般指事務(wù)協(xié)調(diào)者，負(fù)責(zé)協(xié)調(diào)和管理事務(wù)，提供 AP 編程接口或管理 RM 。可以理解為 Spring 中提供的 Transaction Manager；

分布式事務(wù)處理 DTP 模型.png

-TM 和多個 RM 之間的事務(wù)控制，是基于 XA 協(xié)議（XASpecification）來完成的。XA 協(xié)議是 X/Open 提出的分布式事務(wù)處理規(guī)范，也是分布式事務(wù)處理的工業(yè)標(biāo)準(zhǔn)，它定義了 xa_ 和 ax_ 系列的函數(shù)原型及功能描述、約束等。目前 Oracle、MySQL、DB2 都實(shí)現(xiàn)了 XA 接口，所以它們都可以作為 RM；

事務(wù)執(zhí)行流程.png

1.1.2 兩階段提交協(xié)議

• 兩階段：

  • 事務(wù)的準(zhǔn)備階段：事務(wù)管理器（TM）通知資源管理器（RM）準(zhǔn)備分支事務(wù)，記錄事務(wù)日志，并告知事務(wù)管理器的準(zhǔn)備結(jié)果；
  • 事務(wù)的提交或者回滾階段：如果所有的資源管理器（RM）在準(zhǔn)備階段都明確返回成功，則事務(wù)管理器（TM）向所有的資源管理器（RM）發(fā)起事務(wù)提交指令完成數(shù)據(jù)的變更。反之，如果任何一個資源管理器（RM）明確返回失敗，則事務(wù)管理器（TM）會向所有資源管理器（RM）發(fā)送事務(wù)回滾指令；

• 優(yōu)點(diǎn)：簡單，降低事務(wù)提交失敗率；

• 缺點(diǎn)：同步阻塞（對于任何一次指令都必須要有明確的響應(yīng)才能繼續(xù)進(jìn)行下一步）、過于保守（任何一個節(jié)點(diǎn)失敗都會導(dǎo)致數(shù)據(jù)回滾）；

兩階段提交協(xié)議執(zhí)行流程.png

1.1.3 三階段提交協(xié)議

• 三階段：
  • CanCommit（詢問階段）：事務(wù)協(xié)調(diào)者向參與者發(fā)送事務(wù)執(zhí)行請求，詢問是否可以完成指令，參與者只需要回答是或者不是即可，不需要做真正的事務(wù)操作，這個階段會有超時中止機(jī)制；
  • PreCommit（準(zhǔn)備階段）：事務(wù)協(xié)調(diào)者會根據(jù)參與者的反饋結(jié)果決定是否繼續(xù)執(zhí)行，如果在詢問階段所有參與者都返回可以執(zhí)行操作，則事務(wù)協(xié)調(diào)者會向所有參與者發(fā)送 PreCommit 請求，參與者收到請求后寫 redo 和 undo 日志，執(zhí)行事務(wù)操作但是不提交事務(wù)，然后返回 ACK 響應(yīng)等待事務(wù)協(xié)調(diào)者的下一步通知。如果在詢問階段任意參與者返回不能執(zhí)行操作的結(jié)果，那么事務(wù)協(xié)調(diào)者會向所有參與者發(fā)送事務(wù)中斷請求；
  • DoCommit（提交或回滾階段）：這個階段也會存在兩種結(jié)果，仍然根據(jù)上一步驟的執(zhí)行結(jié)果來決定 DoCommit 的執(zhí)行方式。如果每個參與者在 PreCommit 階段都返回成功，那么事務(wù)協(xié)調(diào)者會向所有參與者發(fā)起事務(wù)提交指令。反之，如果參與者中的任一參與者返回失敗，那么事務(wù)協(xié)調(diào)者就會發(fā)起中止指令來回滾事務(wù)；
• 優(yōu)點(diǎn)：可以盡早發(fā)現(xiàn)無法執(zhí)行操作而中止后續(xù)的行為；在準(zhǔn)備階段后，事務(wù)協(xié)調(diào)者和參與者都引入了超時機(jī)制；基于超時機(jī)制來避免資源的永久鎖定；
• 缺點(diǎn)：一旦超時，仍然可能出現(xiàn)數(shù)據(jù)不一致的情況；

三階段提交協(xié)議執(zhí)行流程.png

1.2 分布式事務(wù)的兩個理論模型

1.2.1 CAP 定理

• 與《微服務(wù)架構(gòu) | 3. 注冊中心與服務(wù)發(fā)現(xiàn)》中講解的一樣，指在分布式系統(tǒng)中不可能同時滿足一致性（C:Consistency）、可用性（A:Availability）、分區(qū)容錯性（P:Partition Tolerance）這三個基本需求，最多同時滿足兩個；
  • C：數(shù)據(jù)在多個副本中要保持強(qiáng)一致，比如前面說的分布式數(shù)據(jù)一致性問題；
  • A：系統(tǒng)對外提供的服務(wù)必須一直處于可用狀態(tài)，在任何故障下，客戶端都能在合理的時間內(nèi)獲得服務(wù)端的非錯誤響應(yīng)；
  • P：在分布式系統(tǒng)中遇到任何網(wǎng)絡(luò)分區(qū)故障，系統(tǒng)仍然能夠正常對外提供服務(wù)；
• 網(wǎng)絡(luò)分區(qū)：不同節(jié)點(diǎn)分布在不同的子網(wǎng)絡(luò)中時，在內(nèi)部子網(wǎng)絡(luò)正常的情況下，由于某些原因?qū)е逻@些子節(jié)點(diǎn)之間出現(xiàn)網(wǎng)絡(luò)不通的情況，導(dǎo)致整個系統(tǒng)環(huán)境被切分成若干獨(dú)立的區(qū)域，這就是網(wǎng)絡(luò)分區(qū)；
• 在分布式系統(tǒng)中，不會選擇 CA，而是 AP 和 CP；
  • AP：放棄了強(qiáng)一致性，實(shí)現(xiàn)最終的一致，是很多互聯(lián)網(wǎng)公司解決分布式數(shù)據(jù)一致性問題的主要選擇；
  • CP：放棄了高可用性，實(shí)現(xiàn)強(qiáng)一致性。前面提到的兩階段提交和三階段提交都采用這種方案。可能導(dǎo)致的問題是用戶完成一個操作會等待較長的時間；
  • CA：無法同時做到保證數(shù)據(jù)一致性和可用，要保證數(shù)據(jù)一致性可能要拒絕客戶端請求，除非網(wǎng)絡(luò)百分百可靠；

1.2.2 BASE 理論

• BASE 理論是由于 CAP 中一致性 C 和可用性 A不可兼得而衍生出來的一種新的思想，BASE 理論的核心思想是通過犧牲數(shù)據(jù)的強(qiáng)一致性來獲得高可用性。它有如下三個特性；
  • Basically Available（基本可用）：分布式系統(tǒng)在出現(xiàn)故障時，允許損失一部分功能的可用性，保證核心功能的可用；
  • Soft State（軟狀態(tài)）：允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，這個狀態(tài)不影響系統(tǒng)的可用性，也就是允許系統(tǒng)中不同節(jié)點(diǎn)的數(shù)據(jù)副本之間的同步存在延時；
  • Eventually Consistent（最終一致性）：中間狀態(tài)的數(shù)據(jù)在經(jīng)過一段時間之后，會達(dá)到一個最終的數(shù)據(jù)一致性；
• BASE 理論并沒有要求數(shù)據(jù)的強(qiáng)一致，而是允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但是數(shù)據(jù)最終會在某個時間點(diǎn)實(shí)現(xiàn)一致；
• 在互聯(lián)網(wǎng)產(chǎn)品中，大部分都會采用 BASE 理論來實(shí)現(xiàn)數(shù)據(jù)的一致，因?yàn)楫a(chǎn)品的可用性對于用戶來說更加重要；
• 舉個例子，在電商平臺中用戶發(fā)起一個訂單的支付，不需要同步等待支付的執(zhí)行結(jié)果，系統(tǒng)會返回一個支付處理中的狀態(tài)到用戶界面。對于用戶來說，他可以從訂單列表中看到支付的處理結(jié)果。而對于系統(tǒng)來說，當(dāng)?shù)谌降闹Ц短幚沓晒χ?，再更新該訂單的支付狀態(tài)即可。在這個場景中，雖然訂單的支付狀態(tài)和第三方的支付狀態(tài)存在短期的不一致，但是用戶卻獲得了更好的產(chǎn)品體驗(yàn)；

1.3 分布式事務(wù)問題的常見解決方案（事務(wù)模式）

在互聯(lián)網(wǎng)場景中更多采用柔性事務(wù)，所謂的柔性事務(wù)是遵循 BASE 理論來實(shí)現(xiàn)的事務(wù)模型，它有兩個特性：基本可用、柔性狀態(tài)；

1.3.1 TCC 補(bǔ)償型方案

• TCC（Try-Confirm-Cancel）是一種比較成熟的分布式數(shù)據(jù)一致性解決方案，它實(shí)際上是把一個完整的業(yè)務(wù)拆分為如下三個步驟：
  • Try：這個階段主要是對數(shù)據(jù)的校驗(yàn)或者資源的預(yù)留（凍結(jié)資源）；
  • Confirm：確認(rèn)真正執(zhí)行的任務(wù)，只操作 Try 階段預(yù)留的資源（消耗凍結(jié)資源）；
  • Cancel：取消執(zhí)行，釋放 Try 階段預(yù)留的資源（解凍資源）；
• 其實(shí) TCC 是一種兩階段提交的思想，第一階段通過 Try 進(jìn)行準(zhǔn)備工作，第二階段 Confirm/Cancel 表示 Try 階段操作的確認(rèn)和回滾；
• 在一些特殊情況下，服務(wù)并沒有收到 TCC 事務(wù)協(xié)調(diào)器的 Cancel 或者 Confirm 請求時，可以記錄一些分布式事務(wù)的操作日志，保存分布式事務(wù)運(yùn)行各個階段和狀態(tài)，以實(shí)現(xiàn)一致性；

• TCC 服務(wù)支持接口調(diào)用失敗發(fā)起重試，所以 TCC 暴露的接口都需要滿足冪等性；

  
  
  TCC 方案執(zhí)行流程.png

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

• 基于可靠性消息的最終一致性是互聯(lián)網(wǎng)公司比較常用的分布式數(shù)據(jù)一致性解決方案；
• 它主要利用消息中間件（Kafka、RocketMQ 或 RabbitMQ）的可靠性機(jī)制來實(shí)現(xiàn)數(shù)據(jù)一致性的投遞；
• 在某些場景中可以犧牲數(shù)據(jù)的一致性在短時間內(nèi)不要求實(shí)時性，所以可以采用基于可靠性消息的最終一致性方案來保證最終的數(shù)據(jù)一致性；
• 在消費(fèi)者沒有向消息中間件服務(wù)器發(fā)送確認(rèn)時，這個消息會被重復(fù)投遞，確保消息的可靠性消費(fèi)；
• RocketMQ 使用事件消息模型解決事務(wù)問題，其核心是事務(wù)回查，主要邏輯如下：
  • 生產(chǎn)者發(fā)送一個事務(wù)消息到消息隊(duì)列上，消息隊(duì)列只記錄這條消息的數(shù)據(jù)，此時消費(fèi)者無法消費(fèi)這條消息；
  • 生產(chǎn)者執(zhí)行具體的業(yè)務(wù)邏輯，完成本地事務(wù)的操作；
  • 接著生產(chǎn)者根據(jù)本地事務(wù)的執(zhí)行結(jié)果發(fā)送一條確認(rèn)消息給消息隊(duì)列服務(wù)器，如果本地事務(wù)執(zhí)行成功，則發(fā)送一個 Commit 消息，表示在第一步中發(fā)送的消息可以被消費(fèi)，否則，消息隊(duì)列服務(wù)器會把第一步存儲的消息刪除；
  • 如果生產(chǎn)者在執(zhí)行本地事務(wù)的過程中因?yàn)槟承┣闆r一直未給消息隊(duì)列服務(wù)器發(fā)送確認(rèn)，那么消息隊(duì)列服務(wù)器會定時主動回查生產(chǎn)者獲取本地事務(wù)的執(zhí)行結(jié)果，然后根據(jù)回查結(jié)果來決定這條消息是否需要投遞給消費(fèi)者；
  • 消息隊(duì)列服務(wù)器上存儲的消息被生產(chǎn)者確認(rèn)之后，消費(fèi)者就可以消費(fèi)這條消息，消息消費(fèi)完成之后發(fā)送一個確認(rèn)標(biāo)識給消息隊(duì)列服務(wù)器，表示該消息投遞成功；

RocketMQ 的事件消息模型.png

1.3.3 最大努力通知型

• 與基于可靠性消息的最終一致性方案類似，適用于對數(shù)據(jù)一致性要求不高的場景；
• 在支付服務(wù)沒有返回一個消息確認(rèn)時，支付寶會不斷進(jìn)行重試，直到一個消息確認(rèn)或達(dá)到最大重試次數(shù)；

最大努力通知型.png

1.3.4 AT 模式

• AT 模式是 Seata 最主推的分布式事務(wù)解決方案，它是基于 XA 演進(jìn)而來的一種分布式事務(wù)模式。分為三大模塊：TM、RM 和 TC（與XA不同）。其中：
  • TM 事務(wù)管理器：負(fù)責(zé)向 TC 注冊一個全局事務(wù)，并生成一個全局唯一的 XID。作為 Seata 的客戶端與業(yè)務(wù)系統(tǒng)集成；
  • RM 數(shù)據(jù)庫資源：在業(yè)務(wù)層面通過 JDBC 標(biāo)準(zhǔn)的接口訪問 RM 時， Seata 會對所有請求進(jìn)行攔截。作為 Seata 的客戶端與業(yè)務(wù)系統(tǒng)集成；
  • TC 事務(wù)協(xié)調(diào)器：每個本地事務(wù)進(jìn)行提交時，RM 都會向 TC 注冊一個分支事務(wù)。作為 Seata 的服務(wù)器獨(dú)立部署；
• AT 模式和 XA 一樣，也是一個兩階提交事務(wù)模型；

Seata 的 AT 事務(wù)模式.png

1.3.5 Saga 模式

• Saga 模式又稱為長事務(wù)解決方案，主要描述的是在沒有兩階段提交的情況下如何解決分布式事務(wù)問題；
• 其核心思想是：把一個業(yè)務(wù)流程中的長事務(wù)拆分為多個本地短事務(wù)，業(yè)務(wù)流程中的每個參與者都提交真實(shí)的提交給該本地短事務(wù)，當(dāng)其中一個參與者事務(wù)執(zhí)行失敗，則通過補(bǔ)償機(jī)制補(bǔ)償前面已經(jīng)成功的參與者；
• Saga 的機(jī)制相關(guān)詳情請見筆者的另一篇文章：《微服務(wù)架構(gòu)設(shè)計(jì)模式》讀書筆記 | 第4章 使用Saga管理事務(wù)；

1.5 目前幾種流行的分布式事務(wù)技術(shù)方案對比

2. Seata

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

• 點(diǎn)擊訪問：微服務(wù)架構(gòu) | 11.1 整合 Seata AT 模式實(shí)現(xiàn)分布式事務(wù)；

最后