溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Seata的實現原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
一、背景
二、分布式事務規范
2.1、分布式事務相關概念
2.2、分布式事務實現規范
2.2.1、XA
2.2.2、柔性事務的最終一致性
三、Seata 架構
3.1、系統組成
3.2、工作模式
3.2.1、AT（Auto Transaction）
3.2.2、TCC
3.2.3、XA模式
四、AT 模式核心實現
4.1、事務協調器的啟動
4.2、事務管理器的啟動
4.3、資源管理器的啟動
4.4、全局事務的工作流程
4.4.1、成功的全局事務處理流程
4.4.2、成功的全局事務處理流程
4.5、寫隔離實現
4.6、讀隔離實現
五、總結
大型廠商根據分布式事務實現規范，實現了不同的分布式框架，以簡化業務開發者處理分布式事務相關工作，讓開發者專注于核心業務開發。
Seata就是這么一個分布式事務處理框架，Seata是由阿里開源，前身為Fescar，經過品牌升級變身Seata。
事務：一個程序執行單元，是用戶定義的一組操作序列，需要滿足ACID屬性。
本地事務：事務由本地資源管理器管理。
分布式事務：事務的操作位于不同的節點。
分支事務：在分布式事務中，由資源管理器管理的本地事務。
全局事務：一次性操作多個資源管理器完成的事務，由一組分支事務組成。
對于本地事務，可以借助DBMS系統來實現事務的管理，但是對于分布式事務，它就無能為力了。對于分布式事務，目前主要有2種思路：XA協議的強一致規范以及柔性事務的最終一致性規范。
XA是基于2階段提交協議設計的接口標準，實現了XA規范的資源管理器就可以參與XA全局事務。應用承擔事務管理器TM工作，數據庫承擔資源管理器RM工作，TM生成全局事務id，控制RM的提交和回滾。
該規范主要有3種實現方式，TCC、MQ事務消息、本地消息表。（還存在其他一些不常用實現方式如Saga）。
TCC：try/confirm/cancel，在try階段鎖定資源，confirm階段進行提交，資源鎖定失敗執行cancel階段釋放資源。
MQ事務消息：前提消息系統需要支持事務如RocketMQ，在本地事務執行前，發送事務消息prepare，本地事務執行成功，發送事務消息commit，實現分布式事務最終一致性。如果事務消息commit失敗，RocketMQ會回查消息發送者確保消息正常提交，如果步驟5執行失敗，進行重試，達到最終一致性。
本地消息表：跟MQ事務消息類似，區別在于MQ不支持事務消息，需要借助本地數據庫的事務管理能力。在步驟1中將需要發送的消息和本地事務一起提交到DB，借助DB的事務管理確保消息持久化。步驟2應用通過本地消息表掃描，重試發送，確保消息可以發送成功。
Seata有三個核心組件：
Transaction Coordinator(TC，事務協調器)—— 維護全局事務和分支事務的狀態，驅動全局事務提交或回滾。
Transaction Manager(TM，事務管理器)—— 定義全局事務的范圍，開始事務、提交事務、回滾事務。
Resource Manager(RM，資源管理器)：—— 管理分支事務上的資源，向TC注冊分支事務，匯報分支事務狀態，驅動分支事務的提交或回滾。
三個組件相互協作，TC 以 Server 形式獨立部署，TM和RM集成在應用中啟動，其整體交互如下：
Seata 支持四種工作模式：
AT模式是Seata默認的工作模式。需要基于支持本地 ACID 事務的關系型數據庫，Java 應用，通過 JDBC 訪問數據庫。
整體機制：
該模式是XA協議的演變，XA協議是基于資源管理器實現，而AT并不是如此。AT的2個階段分別是：
一階段：業務數據和回滾日志記錄在同一個本地事務中提交，釋放本地鎖和連接資源。二階段：提交異步化，非常快速地完成；回滾通過一階段的回滾日志進行反向補償。
下圖中，步驟1開啟全局事務；步驟2注冊分支事務，這里對應著一階段；步驟3提交或者回滾分支事務，對應著二階段。
特點：
優點：對代碼無侵入；并發度高，本地鎖在一階段就會釋放；不需要數據庫對XA協議的支持。
缺點：只能用在支持ACID的關系型數據庫；SQL解析還不能支持全部語法。
該模式工作分為三個階段：
上圖中對于多個分支事務，省略了多次出現的 2.* 步驟。對于全局事務執行過程中業務應用宕機情況，業務應用集群中對等節點會通過從TC獲取相關會話，從DB加載詳細信息來恢復狀態機。
特點：
優點：一階段提交本地事務，無鎖，高性能；事件驅動架構，參與者可異步執行，高吞吐；補償服務易于實現。
缺點：不保證隔離性。
XA是基于二階段提交設計的接口標準。對于支持XA的資源管理器，借助Seata框架的XA模式，會使XA方案更簡單易用。使用前提：需要分支數據庫支持XA 事務，應用為 Java應用，且使用JDBC訪問數據庫。
整體機制：
在 Seata 定義的分布式事務框架內，利用事務資源（數據庫、消息服務等）對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種 事務模式。
執行階段：業務sql在XA分支中執行，由分支事務的RM管理器管理，然后執行XA prepare。完成階段：TM根據各個分支執行結果通過TC通知各個分支執行XA commit或者XA rollback。
特點：
優點：繼承了XA協議的優勢，事務具有強一致性。
缺點：同樣繼承了XA協議的劣勢，由于分支事務長時間開啟，并發度低。2.5 Seata 各模式對比
分布式事務方案沒有銀彈，根據自己的業務特性選擇合適的模式。例如追求強一致性，可以選擇AT和XA，存在和外部系統對接，可以選擇Saga模式，不能依賴本地事務，可以采用TCC等等。結合各模式的優缺點進行選擇。
鑒于Seata支持的模式較多，而其默認的模式是AT，為節省篇幅，以下圍繞AT模式分析其相關的核心模塊實現。
TC（事務協調器）以獨立的服務啟動，作為Server，維護全局事務和分支事務的狀態，驅動全局事務提交或回滾。下面是TC的啟動流程：
TM（事務管理器）集成在應用中啟動，負責定義全局事務的范圍，開始事務、提交事務、回滾事務。
TM所在應用中需要配置GlobalTransactionScannerbean，在應用啟動時會進行如下初始化流程：
RM（資源管理器）集成在應用中啟動，負責管理分支事務上的資源，向TC注冊分支事務，匯報分支事務狀態，驅動分支事務的提交或回滾。
RM所在的應用中除了需要跟TM一樣配置GlobalTransactionScanner以啟動RMClient，還需要配置DataSourceProxy，以實現對數據源訪問代理。該數據源代理實現了sql的解析 →生成undo-log →業務sql和undo-log一并本地提交等操作。
下面以一個簡單的例子來說明全局事務的工作原理：
BusinessService：發起購買服務
StorageService：庫存管理服務
購買操作實現在businessService.purchase中，purchase方法實現上通過GlobalTransaction注解，通過Dubbo服務，調用了庫存服務deduct方法方法，樣例如下：
@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")
public void purchase(String userId, String commodityCode, int orderCount) {
storageService.deduct(commodityCode, orderCount);
// throw new RuntimeException("xxx");
}
這里設定BusinessService在成功調用StorageService后，本地出現異常。
全局事務未提交，分支事務本地已經提交的情況下（假設修改了資源A），如何避免其他事務在此時修改資源A？Seata采用全局鎖來實現，其流程如下：
在數據庫本地隔離級別為讀已提交或以上的基礎上，Seata提供了讀未提交，這個很好理解，全局事務提交前分支事務本地已經提交。如果想要實現讀已提交，則需要在select語句上加for update。
Seata是Java領域很強大的分布式事務框架，其支持了多種模式。其中默認支持的AT模式，相比于傳統的2PC協議（基于數據庫的XA協議），很好地解決了2PC長期鎖資源的問題，提高了并發度。Seata支持的各個模式中，AT模式對業務零入侵實現分布式事務，對于開發者更加友好。另外Seata的Server在選擇合適的存儲介質時可以進行集群模式，減少單點故障影響。
“Seata的實現原理是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
