# 分布式事務Seata

## 目錄

  • 8.1 分布式事務問題的理論模型=

  • 8.2 分布式事務問題的常見解決方案

  • 8.3 分布式事務框架Seata

  • 8.4 Seata的安裝

  • 8.5 AT模式Dubbo集成Seata

  • 8.6 Spring Cloud Alibaba Seata

  • 8.7 Seata AT模式的實現原理

  • 8.8 官方文檔

## 分布式事務Seata

提到事務這個概念,相信大家第一-時間想到的是數據庫的事務。所謂的數據庫事務是指作為單個邏輯工作單

元執行的多個數據庫操作,要么同時成功,要么同時失敗,它必須滿足ACID特性,即:

  • ●原子性( Atomicity) :事務必須是原子工作單元,不可繼續分割,要么全部成功,要么全部

  • 失敗。

  • ●-致性( Consistency) : 事務完成時,所有的數據都必須保持一致。

  • ●隔離性( Isolation) :由并發事務所做的修改必須與任何其他并發事務所做的修改隔離。

  • ●持久性( Durability) :事務執行完成之后,它對于系統的影響是永久性的。

上述是針對單庫多表的情況事務所要滿足的特性。在微服務架構下,隨著業務服務的拆分及數據庫的拆分,

會存在如圖8-1所示的場景,訂單和庫存分別拆分成了兩個獨立的數據庫,當客戶端發起一個下單操作時, 需要在訂單服務對應的數據庫中創建訂單,同時需要基于RPC通信調用庫存服務完成商品庫存的扣減。



在這樣一個場景中,原本的單庫事務操作就變成了多個數據庫的事務操作,由于每個數據庫的事務執行情況只有自己知道,比如訂單數據庫并不知道庫存數據庫的執行結果,這樣就會導致訂單數據庫和庫存數據庫的數據不一致問題,比如訂單創建成功,庫存扣減失敗,就可能會導致”超賣”問題。這就是所謂的分布式事務場景。

準確來說,分布式事務是指事務的參與者、支持事務的服務器、資源服務器及事務管理器分別位于分布式系統的不同節點上。

## 8.1分布式事務問題的理論模型

分布式事務問題也叫分布式數據一致性問題,簡單來說就是如何在分布式場景中保證多個節點數據的一致性。分布式事務產生的核心原因在于存儲資源的分布性,比如多個數據庫,或者MySQL和Redis兩種不同存儲設備的數據一致性等。在實際應用中,我們應該盡可能地從設計層面去避免分布式事務的問題,因為任何一-種解決方案都會增加系統的復雜度。接下來我們了解一下分 布式事務問題的常見解決方案。

### 8.1.1 X/Open分布式事務模型

- X/Open DTP ( X/Open Distributed Transaction Processing Reference Model )是X/Open這個組織定義的一套分布式事務的標準。這個標準提出了使用兩階段提交( 2PC, Two- Phase-Commit )來保證分布式事務的完整性。如圖8-2所示,X/Open DTP中包含以下三種角色。

  • - . AP : Application,表示應用程序。

  • - ●RM: Resource Manager ,表示資源管理器,比如數據庫。

  • - ●TM: Transaction Manager,表示事務管理器,-般指事務協調者,負責協調和管理事務,提供AP編程接口或管理RM。可以理解為Spring中提供的Transaction Manager。

- 圖8-2所展示的角色和關系與本地事務的原理基本相同,唯一-不同的在于 ,如果此時RM代表數據庫,那么TM需要能夠管理多個數據庫的事務,大致實現步驟如下:



  • - ●配置TM,把多個RM注冊到TM ,相當于TM注冊RM作為數據源。

  • - ●AP從TM管理的RM中獲取連接,如果RM是數據庫則獲取JDBC連接。

  • - ●AP向TM發起一個全局事務,生成全局事務ID ( XID) , XID會通知各個RM。

  • - ●AP通過第二步獲得的連接直接操作RM完成數據操作。這時, AP在每次操作時會把XID傳遞給RM。

  • - ●AP結束全局事務, TM會通知各個RM全局事務結束。

  • - ●根據各個RM的事務執行結果,執行提交或者回滾操作。

- 為了更清晰地理解,讀者可參考如圖8- 3所示的流程圖,實際上這里會涉及全局事務的概念。也就是說,在原本的單機事務下,會存在跨庫事務的可見性問題,導致無法實現多節點事務的全局可控。而TM就是一個全局事務管理器,它可以管理多個資源管理器的事務。TM最終會根據各個分支事務的執行結果進行提交或者回滾,如果注冊的所有分支事務中任何一個節點事務執行失敗,為了保證數據的一致性, TM會觸發各個RM的事務回滾操作。



- 需要注意的是,TM和多個RM之間的事務控制,是基于XA協議( XA Specification )來完成的。XA協議是X/Open提出的分布式事務處理規范,也是分布式事務處理的工業標準,它定義了xa,和ax_系列的函數原型及功能描述、約束等。目前Oracle、MySQL、 DB2都實現了XA接口,所以它們都可以作為RM。

### 8.1.2兩階段提交協議

- 細心的讀者不難發現,在圖8-3中TM實現了多個RM事務的管理,實際上會涉及兩個階段的提交,第- -階段是事務的準備階段,第二階段是事務的提交或者回滾階段。這兩個階段都是由事務管理器發起的。兩階段提交協議的執行流程如下。

  • - ●準備階段:事務管理器(TM)通知資源管理器(RM)準備分支事務,記錄事務日志,并告知事務管理器的準備結果。

  • - ●提交/回滾階段:如果所有的資源管理器( RM )在準備階段都明確返回成功,則事務管理器( TM )向所有的資源管理器( RM )發起事務提交指令完成數據的變更。反之,如果任何一個資源管理器( RM )明確返回失敗,則事務管理器( TM )會向所有資源管理器( RM )發送事務回滾指令。完整的執行流程如圖8- 4所示。

- 兩階段提交將- -個事務的處理過程分為投票和執行兩個階段,它的優點在于充分考慮到了分布式系統的不可靠因素,并且采用非常簡單的方式(兩階段提交)就把由于系統不可靠而導致事務提交失敗的概率降到最小。當然,它也并不是完美的,存在以下缺點。



  • - ●同步阻塞:從圖8-4的執行流程來看,所有參與者( RM )都是事務阻塞型的,對于任何一次指令都必須要有明確的響應才能繼續進行下一-步 ,否則會處于阻塞狀態,占用的資源一-直被鎖定。

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

  • - ●事務協調者的單點故障:如果協調者在第二階段出現了故障,那么其他的參與者( RM)會一直處于鎖定狀態。

  • - ●“腦裂”導致數據不一致問題:在第二階段中,事務協調者向所有參與者( RM )發送commit請求后,發生局部網絡異常導致只有一部分參與者( RM )接收到了commit請求,這部分參與者( RM )收到請求后會執行commit操作,但是未收到commit請求的節點由于事務無法提交,導致數據出現不一致問題。

### 8.1.3三階段提交協議

- 三階段提交協議是兩階段提交協議的改進版本,它利用超時機制解決了同步阻塞的問題,三階段提交協議的具體描述如下。



  • - ●CanCommit (詢問階段) :事務協調者向參與者發送事務執行請求,詢問是否可以完成指令,參與者只需要回答是或者不是即可,不需要做真正的事務操作,這個階段會有超時中止機制。

  • - , PreCommit (準備階段) :事務協調者會根據參與者的反饋結果決定是否繼續執行,如果在詢問階段所有參與者都返回可以執行操作,則事務協調者會向所有參與者發送PreCommit請求,參與者收到請求后寫redo和undo日志,執行事務操作但是不提交事務,然后返回ACK響應等待事務協調者的下一-步通知。如果在詢問階段任意參與者返回不能執行操作的結果,那么事務協調者會向所有參與者發送事務中斷請求。

  • - ●DoCommit (提交或回滾階段) :這個階段也會存在兩種結果,仍然根據上一步驟的執行結果來決定DoCommit的執行方式。如果每個參與者在PreCommit階段都返回成功,那么事務協調者會向所有參與者發起事務提交指令。反之,如果參與者中的任一參 與者返回失敗,那么事務協調者就會發起中止指令來回滾事務。

- 三階段提交協議和兩階段提交協議相比有一-些不同點:,

  • - 增加了一個CanCommit階段,用于詢問所有參與者是否可以執行事務操作并且響應,它的好處是,可以盡早發現無法執行操作而中止后續的行為。

  • - ●在準備階段之后 ,事務協調者和參 與者都引入了超時機制,- -旦超時 ,事務協調者和參 與者會繼續提交事務,并且認為處于成功狀態,因為在這種情況下事務默認為成功的可能性比較大。

- 實際上,一旦超時,在三階段提交協議下仍然可能出現數據不一致的情況,當然概率是比較小的。另外,最大的好處就是基于超時機制來避免資源的永久鎖定。需要注意的是,不管是兩階段提交協議還是三階段提交協議,都是數據-致性解決方案的實現,我們可以在實際應用中靈活調整。比如ZooKeeper集群中的數據一致性,就用到了優化版的兩階段提交協議,優化的地方在于,它不需要所有參與者在第一-階段返回成功才能提交事務,而是利用少數服從多數的投票機制來完成數據的提交或者回滾。