重慶分公司
重慶分公司，新征程啟航
為企業提供網站建設、域名注冊、服務器等服務
什么是seata源碼
本篇內容介紹了“什么是seata源碼”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
為延津等地區用戶提供了全套網頁設計制作服務，及延津網站建設行業解決方案。主營業務為成都網站制作、成都做網站、延津網站設計，以傳統方式定制建設網站，并提供域名空間備案等一條龍服務，秉承以專業、用心的態度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
seata源碼閱讀筆記
本文沒有seata的使用方法，怎么使用seata可以參考官方示例，詳細的很。
本文基于v0.8.0版本，本文沒貼代碼。
seata中的三個重要部分：
TC：事務協調器，維護全局事務和分支事務的狀態，驅動全局提交或回滾，就是seata的服務端。
TM：事務管理器，開始全局事務，提交或回滾全局事務。
RM：資源管理器，管理正在處理的分支事務的資源，向TC注冊并報告分支事務的狀態，并驅動分支事務的提交或回滾。
seata的初始化
TC啟動
RM發送jdbcUrl、applicationId和transactionServiceGroup三個參數向TC發起注冊，建立連接。入口是在
DataSourceProxy實例化的時候TM發送applicationId和transactionServiceGroup兩個參數向TC發起注冊，建立連接。
TM-處理全局事務
全局事務發起者，就是我們加@GlobalTransactional注解的方法，seata會代理我們的方法，通過以下步驟來完成全局事務。
發送全局事務開始請求到TC，TC返回xid(全局事務唯一id)，將xid綁定到當前線程
執行我們的業務邏輯
業務邏輯成功，發送全局事務commit請求到TC，如果失敗則重試
業務邏輯異常（可配置回滾規則，即哪些異常回滾），發送全局事務rollback請求到TC，如果失敗則重試
清理資源，事務結束
源碼閱讀入口：io.seata.spring.annotation.GlobalTransactionalInterceptor#invoke
RM-處理分支事務
rm需要代理我們項目中的數據源，這一步需要我們修改自己的代碼，如下：
@Configuration
public class DataSourceConfig {
@Bean
@ConfigurationProperties(prefix = "spring.datasource")
public DataSource druidDataSource() {
return new DruidDataSource();
}
/**
* 需要將DataSourceProxy 設置為主數據源，否則事務無法回滾
*/
@Primary
@Bean("dataSource")
public DataSource dataSource(DataSource druidDataSource) {
return new io.seata.rm.datasource.DataSourceProxy(druidDataSource);
}代理數據源的主要目的是代理數據庫連接，這樣就可以控制分支事務的commit、rollback。
seate的rm-datasoure模塊中有這幾個代理類DataSourceProxy、ConnectionProxy、StatementProxy，通過代理jdbc中的這幾個類，讓我們的sql通過ExecuteTemplate來進行執行，這個類就是我們了解seata怎么控制分支事務的入口。下面看分支事務的處理步驟：
將xid綁定到當前數據庫連接（xid怎么來的？在后面）
拿到sql執行前數據庫表中的數據記錄beforeImage（只是受影響的數據及字段，通過解析我們的sql完成）
執行我們的業務sql
拿到sql執行后數據庫表中的數據記錄afterImage
用變動數據的主鍵值作為lockKey，并保存到當前數據庫連接中
將beforeImage和afterImage轉換成undo log，并保存到當前數據庫連接中
向TC發送全局鎖請求（帶著xid和lockKey），TC返回branchId，表示拿到了全局鎖，若不成功則重試（默認30次，每次間隔10ms）；這個全局鎖的是為了防止多個用戶同時對同一數據進行修改，造成后面通過undo_log進行回滾操作時數據出錯；這個鎖在PhaseTwo完成后，TC會進行釋放。
將undoLog保存到數據庫的undo_log表中
提交數據庫事務
向TC報告當前分支事務commit的結果（失敗或成功），若報告不成功則重試（默認5次）
commit成功后，清理當前數據庫連接綁定的xid
commit失敗后，向上拋出異常，以便讓tm知道，進行全局事務的回滾
這是PhaseOne的整個過程，下面看PhaseTwo：
tc收到tm的全局事務提交或回滾請求后，會對這個全局事務中的所有分支事務進行通知，rm在收到通知后，進行回滾或者提交的操作
回滾：取出數據庫undo_log進行數據補償還原，成功后刪除undo_log；提交：直接刪除undo_log
返回tc處理結果
源碼閱讀入口： io.seata.rm.datasource.StatementProxy#execute
XID在服務鏈路中的傳遞
dubbo
用dubbo的filter實現的，源碼：io.seata.integration.dubbo.TransactionPropagationFilter
原理就是：上游在filter中把xid放到RpcContext中，下游再從RpcContext拿到xid。
RestTemplate和Feign
對RestTemplate和Feign的支持不在seata-all中，而是在spring-cloud-alibaba-seata中
源碼入口：
com.alibaba.cloud.seata.rest.SeataRestTemplateAutoConfiguration com.alibaba.cloud.seata.feign.SeataFeignClientAutoConfiguration com.alibaba.cloud.seata.web.SeataHandlerInterceptorConfiguration
原理就是：上游通過攔截器將xid放到請求的header中，下游通過攔截器從header中拿到xid。
seata還支持很多RPC框架，如sofa-rpc、motan等。我們也可以通過類似的方法使seata支持我們自己的rpc框架。
GlobalLock注解
如果是用 GlobalLock 修飾的本地業務方法，雖然該方法并非某個全局事務下的分支事務，但是它對數據資源的操作也需要先查詢全局鎖，如果存在其他 Seata 全局事務正在修改，則該方法也需等待。所以，如果想要Seata 全局事務執行期間，數據庫不會被其他事務修改，則該方法需要強制添加 GlobalLock 注解，來將其納入 Seata 分布式事務的管理范圍。
功能有點類似于 Spring 的 @Transactional 注解，如果你希望開啟事務，那么必須添加該注解，如果你沒有添加那么事務功能自然不生效，業務可能出 BUG；Seata 也一樣，如果你希望某個不在全局事務下的 SQL 操作不影響 AT 分布式事務，那么必須添加 GlobalLock 注解。
TC的高可用設計
seata服務端支持zk、nacos、eureka等作為服務發現，通過數據庫實現數據共享，全局事務Session信息、分支事務Session信息，全局鎖信息都是放在數據庫中
TCC模式
TCC和AT的不同主要體現在RM這邊，TC和TM都是一樣的。
TCC的RM不會代理我們的數據源了，而是由我們自己指定rollback和commit邏輯，在二階段中，TM在發起全局事務提交回滾時，RM只需要執行我們指定的rollback和commit方法就行了。
這種模式就是我們業務代碼的變動要多些，效率是要比AT模式高些。
RM一階段源碼入口：io.seata.spring.tcc.TccActionInterceptor#invoke
RM二階段源碼入口：io.seata.rm.tcc.TCCResourceManager#branchCommit#branchRollback
“什么是seata源碼”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注創新互聯網站，小編將為大家輸出更多高質量的實用文章！
本文題目：什么是seata源碼
網站地址：http://www.xueling.net.cn/article/ijigdi.html