Spring Cloud Alibaba分布式事務解決框架Seata概念入門篇
Seata中文參考文檔： http://seata.io/zh-cn/docs/overview/what-is-seata.html
前言
繼上一篇文章 分布式事務解決方案及理論基礎入門 介紹了分布式解決方案相關概念之后，本篇給大家帶來Spring Cloud Alibaba開源的一款分布式解決方案框架Seata，本篇為Seata組件的相關概念介紹，如果想使用Seata實戰解決分布式事務難題還請看下一篇文章。
一、什么是微服務架構
“微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務和服務之間采用輕量級的通信機制相互溝通(通常是基于HTTP的Restful API).每個服務都圍繞著具體的業務進行構建，并且能夠被獨立的部署到生產環境、類生產環境等。另外，應盡量避免統一的、集中的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建"
二、分布式事務的產生
1. 單體架構
一個用戶完整的下單過程，在單體應用中，只需要一個在一個項目中，一個數據庫里，通過調用下下單接口，下單時調用扣減庫存方法和扣減賬戶余額來完成一筆訂單。
2. 分布式架構
單體應用被拆分成微服務應用，原來的三個模塊被拆分成三個獨立的應用，分別使用不同的數據源，在業務操作上需要調用三個服務來完成。此時每個服務內部的數據一致性由本地事務來保證，但是全局的數據一致性問題沒法保證，分布式事務由此產生。
三、Seata的4種事務模式
1. Seata是什么
Seata 是一款開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，默認使用AT模式，為用戶打造一站式的分布式解決方案。
2. AT 模式
前提
- 基于支持本地 ACID 事務的關系型數據庫。
- Java 應用，通過 JDBC 訪問數據庫。
整體機制
通過2PC兩階段提交協議的演變：
- 一階段： 業務數據和回滾日志記錄在同一個本地事務中提交，釋放本地鎖和連接資源。
- 二階段： 提交異步化，成功則批量地刪除相應回滾日志記錄，失敗則通過回滾日志進行反向補償。
寫隔離
- 1)、 一階段本地事務提交前，需要確保先拿到全局鎖。
- 2)、拿不到全局鎖，不能提交本地事務;拿到全局鎖，提交本地事務并插入undo_log記錄。
- 3)、拿全局鎖的嘗試被限制在一定范圍內，超出范圍將放棄，并根據undo_log記錄回滾本地事務，釋放本地鎖。
讀隔離
1)、在數據庫本地事務隔離級別 讀已提交(Read Committed) 或以上的基礎上，Seata(AT 模式)的默認全局隔離級別是 讀未提交(Read Uncommitted)。
理解： 在全局事務提交之前，本地事務會先提交，這時候查詢數據，對于本地庫是Read Committed，對于全局來說是 Read Uncommitted。
2)、如果要求全局的讀已提交，目前 Seata 的方式是通過 SELECT FOR UPDATE 語句的代理。
3. TCC模式
TCC不依賴 RM 對分布式事務的支持，而是通過對業務邏輯的分解來實現分布式事務。
- 1)、初步操作 Try： 完成所有業務檢查，預留必須的業務資源。
- 2)、確認操作 Confirm： 真正執行的業務邏輯，不做任何業務檢查，只使用 Try 階段預留的業務資源。因此，只要 Try 操作成功，Confirm 必須能成功。另外，Confirm 操作需滿足冪等性，保證一筆分布式事務能且只能成功一次。
- 3)、取消操作 Cancel： 釋放 Try 階段預留的業務資源。同樣的，Cancel 操作也需要滿足冪等性。
所謂 TCC 模式，是指支持把 自定義 的分支事務納入到全局事務的管理中。
4. SAGA模式
概述
Seata提供的長事務解決方案，在Saga模式中，業務流程中每個參與者都提交本地事務，當出現某一個參與者失敗則補償前面已經成功的參與者，一階段正向服務和二階段補償服務都由業務開發實現。
適用場景：
- 業務流程長、業務流程多
- 參與者包含其它公司或遺留系統服務，無法提供 TCC 模式要求的三個接口
優勢：
- 一階段提交本地事務，無鎖，高性能
- 事件驅動架構，參與者可異步執行，高吞吐
- 補償服務易于實現
缺點：
不保證隔離性
基于狀態機引擎的 Saga 實現。
目前SEATA提供的Saga模式是基于狀態機引擎來實現的，機制是：
- 通過狀態圖來定義服務調用的流程并生成 json 狀態語言定義文件。
- 狀態圖中一個節點可以是調用一個服務，節點可以配置它的補償節點。
- 狀態圖 json 由狀態機引擎驅動執行，當出現異常時狀態引擎反向執行已成功節點對應的補償節點將事務回滾，異常發生時是否進行補償也可由用戶自定義決定。
- 可以實現服務編排需求，支持單項選擇、并發、子流程、參數轉換、參數映射、服務執行狀態判斷、異常捕獲等功能。
示例狀態圖：
5. XA 模式
前提
- 支持XA 事務的數據庫。
- Java 應用，通過 JDBC 訪問數據庫。
整體機制
在 Seata 定義的分布式事務框架內，利用事務資源(數據庫、消息服務等)對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種 事務模式。
執行階段：
- 可回滾：業務 SQL 操作放在 XA 分支中進行，由資源對 XA 協議的支持來保證 可回滾
- 持久化：XA 分支完成后，執行 XA prepare，同樣，由資源對 XA 協議的支持來保證 持久化(即，之后任何意外都不會造成無法回滾的情況)
完成階段：
- 分支提交：執行 XA 分支的 commit
- 分支回滾：執行 XA 分支的 rollback
關于XA模式的介紹這里先簡單提一下，更詳細的信息查閱 ：http://seata.io/zh-cn/docs/dev/mode/xa-mode.html
四、Seata模型介紹
Seata的整個過程模型如下圖所示：
上圖中主要有三種角色：
- TM：事務管理者，用來告訴 TC，全局事務的開始，提交，回滾。
- TC：事務協調者，即seata-server，維護全局事務和分支事務的狀態，通知各RM提交或者回滾。
- RM：資源管理者，每一個 RM 都會作為一個分支事務注冊在 TC，負責分支事務的注冊、提交和回滾。
術語介紹：
- XID - Transaction ID ，一個分布式事務唯一一個ID。
- TC - 事務協調者，維護全局和分支事務的狀態，驅動全局事務提交或回滾。
- TM - 事務管理器，定義全局事務的范圍：開始全局事務、提交或回滾全局事務。
- RM - 資源管理器，管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。
典型的分布式事務處理流程包括以下步驟：
- TM向TC請求開啟一個全局事務，TC給TM返回一個全局事務的XID，即XID;
- XID在微服務調用鏈路的上下文間傳播;
- RM向TC注冊分支事務，將其納入XID對應全局事務的管轄;
- TM根據XID向TC發出提交或者回滾的請求;
- TC根據XID使RM提交或者回滾
流程圖如下：
五、關于Seata架構
早在2019年，阿里開源了分布式事務框架Seata，原名叫Fescar，后來跟螞蟻TCC方案整合后改名為Seata，截止目前2020年11月3日，Seata已經更新到v1.4.0版本了，雖然在之前的版本發布中，存在一些潛在的問題，但是通過開源團隊快速修復問題，并且快速迭代發布新版本之下，目前相對較穩定。
同時相比與其它分布式事務框架，Seata架構的亮點主要有幾個：
- 應用層基于SQL解析實現了自動補償，從而最大程度的降低業務侵入性;
- 將分布式事務中TC(事務協調者)獨立部署，負責事務的注冊、回滾;
- 通過全局鎖實現了寫隔離與讀隔離。
六、參考文檔
Seata中文官方文檔： http://seata.io/zh-cn/docs/overview/what-is-seata.html
Seata-Server下載地址： https://github.com/seata/seata/releases
分布式事務Demo： https://github.com/seata/seata-samples
Seata源碼地址： https://github.com/seata/seataSeata中文參考文檔： http://seata.io/zh-cn/docs/overview/what-is-seata.html
