分布式事務解決方案Seata


Seata全稱是Simple Extensible Autonomous Transaction Architecture,是由阿里巴巴開源的具有高性能和易用性的分布式事務解決方案。

微服務中的分布式事務問題

我們的電商系統使用的是微服務架構,由倉儲服務、訂單服務、賬戶服務組成,三個服務分別有着自己的本地數據源。開始事務后,每個服務本身能保證數據一致性,但是服務之間將無法保證數據一致性。這也許是很多企業遇到的問題,而Seata就是解決此類問題的。

Seata組織結構

  • 事務協調器(TC):維護全局和分支事務的狀態,驅動全局提交或回滾。

  • 事務管理器(TM):定義全局事務的范圍:開始全局事務、提交或回滾全局事務。

  • 資源管理器(RM):管理分支事務處理的資源,與TC交談以注冊分支事務和報告分支事務的狀態,並驅動分支事務提交或回滾。

Seata管理的分布式事務的典型生命周期

  • TM要求TC開始新的全局事務。TC生成代表全局事務的XID。

  • XID通過微服務的調用鏈傳播。

  • RM將本地事務注冊為XID到TC的相應全局事務的分支。

  • TM請求TC提交或回滾XID的相應全局事務。

  • TC驅動XID對應全局事務下的所有分支事務,完成分支提交或回滾。

Seata AT 模式

寫隔離

  • 一階段本地事務提交前,需要確保先拿到全局鎖 。
  • 拿不到全局鎖不能提交本地事務。
  • 拿全局鎖的嘗試被限制在一定范圍內,超出范圍將放棄,並回滾本地事務,釋放本地鎖。

舉例說明:

兩個全局事務 tx1 和 tx2,分別對 a 表的 m 字段進行更新操作,m 的初始值 1000。

tx1 先開始,開啟本地事務,拿到本地鎖,更新操作 m = 1000 - 100 = 900。本地事務提交前,先拿到該記錄的 全局鎖 ,本地提交釋放本地鎖。 tx2 后開始,開啟本地事務,拿到本地鎖,更新操作 m = 900 - 100 = 800。本地事務提交前,嘗試拿該記錄的 全局鎖 ,tx1 全局提交前,該記錄的全局鎖被 tx1 持有,tx2 需要重試等待 全局鎖 。

tx1 二階段全局提交,釋放 全局鎖 。tx2 拿到 全局鎖 提交本地事務。

讀隔離

Seata(AT 模式)的默認全局隔離級別是讀未提交,必須將其全局隔離級別修改為讀已提交

SEATA Saga 模式

Saga模式是SEATA提供的長事務解決方案,在Saga模式中,業務流程中每個參與者都提交本地事務,當出現某一個參與者失敗則補償前面已經成功的參與者,一階段正向服務和二階段補償服務都由業務開發實現。

目前SEATA提供的Saga模式是基於狀態機引擎來實現的,機制是:

  • 通過狀態圖來定義服務調用的流程並生成 json 狀態語言定義文件
  • 狀態圖中一個節點可以是調用一個服務,節點可以配置它的補償節點
  • 狀態圖 json 由狀態機引擎驅動執行,當出現異常時狀態引擎反向執行已成功節點對應的補償節點將事務回滾 注意:異常發生時是否進行補償也可由用戶自定義決定
  • 可以實現服務編排需求,支持單項選擇、並發、子流程、參數轉換、參數映射、服務執行狀態判斷、異常捕獲等功能


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM