簡介
SEATA是阿里巴巴開源的分佈式事務解決方案，用於解決分佈式系統中的數據一致性問題。分佈式系統，數據存儲在不同的資源管理器(數據庫)，需要保證分佈式事務的原子性，業界比較常用xa，數據庫標準實現，嚴格的一致性，但性能差，不符合當前互聯網體系高吞吐，高併發的要求。Seata提供最終一致性的分佈式事務解決方案，犧牲嚴格一致性，允許一定時間的不一致，獲得高性能。
seata支持tcc，saga，at，xa ，本文分析seata的tcc事務模式，based seata v2.0.0，
分3篇：1 織入攔截器， rpc，資源分析
2 事務流程，包括tm啓動全局事務，rm註冊事務分支，執行業務邏輯，rm報告分支狀態，tm結束事務，tc通知rm結束事務，rm結束事務
3 健壯性 fence組件，冪等、懸掛和空回滾
關鍵詞
分佈式事務
嚴格一致性
最終一致性
Transaction Coordinator（TC）：負責全局事務的生命週期管理和協調，保證所有分支事務的一致性。
Transaction Manager（TM）：負責分支事務的提交和回滾，接受TC的指令並執行相應的全局事務操作。
Resource Manager（RM）：負責本地事務的提交和回滾，與TM進行通信，執行相應的分支事務操作。
參考資料
seata官方網站 https://seata.apache.org/
技術架構
seata的技術架構，分4個內容部分，事務框架流程，應用端組件(左側)，服務組件(右側)，功能組件就是上圖
事務框架流程
技術架構圖展示事務框架流程，
1、開啓全局事務，使用@GlobalTransactional方法調起執行切面，向TC註冊全局事務，TC生成XID，返回給TM
2、分支事務註冊，經過切面向業務服務置入邏輯，業務服務調用前執行，註冊分支事務，從TC獲得分支事務ID，TC根據XID將分支事務與全局事務關聯
3、分支事務報告，業務服務執行自身業務邏輯，例如執行sql，寫入數據庫，若成功，通知TC分支事務成功
步驟3，4通常多個業務服務
4、全局提交事務或回滾，分支服務全部成功，TM通知TC全局事務成功；否則，通知TC全局事務失敗；
5、分支事務提交或回滾， TC收到全局事務的結果，若成功，則通知RM成功，RM收到通知後執行清理工作；如果失敗了，則RM進行回滾。
總述通用分佈式事務流程，各模式”塞”進框架內，為了維持表面上的“團結”，seata內部採用了很多的設計，下面及後面章節詳細分析。就是，seata的框架流程
TCC
本節分析tcc模式的原理和源碼
織入tcc攔截器
seata初始化的核心工作，seata使用aop機制，無侵入方式安插自身的事務邏輯到用户的業務就是織入tcc攔截器
上圖是織入攔截器相關用例，大致兩個事情
- 分析資源(bean，方法)，返回合適切面，織入切面
- 向tc註冊
類圖
下圖織入攔截器的類圖
GlobalTransactionScanner 繼承AbstractAutoProxyCreator，該類是spring aop包的成員，主要方式wrapIfNecessary，繼承類覆蓋該方法，按自身需要，通常類類型或註解，對類型織入切面，seata使用該機制織入切面
@GlobalTransactional和@TwoPhaseBusinessActiontcc相關的兩個註解，前者織入全局事務的攔截器GlobalTransactionalInterceptorHandler；後者插入分支事務的攔截器TccActionInterceptorHandler
AdapterSpringSeataInterceptorspring aop的攔截器適配完成，適配seata自身機制的handler，這樣設計許可讓seata自身的handler使用其他織入框架，如，google juice
GlobalTransactionalInterceptorHandler處理事務全局的攔截器，後面章節詳細分析
TccActionInterceptorHandlertcc分支事務的攔截器
InterfaceParser分析bean的類型信息，註解信息，選擇適當的攔截器，tcc模式的InterfaceParserTccActionInterceptorParser就是實現，該分析器還負責資源註冊
rpc框架
本節簡單介紹rpc框架，研讀過阿里系組件源碼的都知道，阿里的開源組件的rpc設計很類似，如之前研究過的raft組件dledger，sentinel，flink，總體來説3要素，NettyRemotingClient，NettyRemotingServer，處理器
client就是Seata，tc是rpc的server端， tm，rm
TC側
tc處理器處理來自tm，rm的消息
NettyRemotingServer
上圖是tc處理tm，rm遠程請求的處理器的註冊點，也是分析tc端關鍵入口，從消息類型(MessageType) 知道消息的用途，
ServerOnRequestProcessor只是門面，實際處理交給TransactionMessageHandler處理，該類的實現類DefaultCoordinator，消息處理代碼有點繞，主要是適配幾種模式，獲取上下文，這裏不深入分析。
TM側
通過相應地，tm側處理器註冊，能夠看到消息類型大部分帶“RESULT”，處理tc返回的消息
TmNettyRemotingClient
RM側
rm 資源管理器，消息處理器處理來自tc的指令或者處理結果
RmNettyRemotingClient
資源分析
本節介紹資源分析，資源分析是配合aop機制，分析spring管理的bean，篩選出目標bean，獲取 seata註解，手段類型信息，決定哪種事務模式，使用哪個攔截器
上圖資源分析的類圖，分析器主要作用是返回織入的攔截器
GlobalTransactionScanner前面介紹過，負責檢測spring管理對象是否參與分佈式事務，織入seata邏輯，檢測工具是資源(對象)分析器，InterfaceParser
DefaultInterfaceParser使用spi機制聚合分析器搭建，遍歷探測，直到解釋成功。
GlobalTransactionalInterceptorParser分析全局事務，查看方法是否有@GlobalTransactional，返回全局事務攔截器GlobalTransactionalInterceptorHandler，負責處理全局事務，全局鎖
TccActionInterceptorParse檢查方法是否有@TwoPhaseBusinessAction，該註解帶tcc的commit/rollback方法名稱的屬性，返回TccActionInterceptorHandler，tcc的攔截器
GlobalTransactionalInterceptorHandler是全局事務攔截器，所有事務模式都使用到，TccActionInterceptorHandler是tcc攔截器
*xa/at沒有分支的切面，而是使用jdbc代理織入分支邏輯
> 註冊資源
tcc資源是資源管理器服務，註冊資源是註冊資源管理器服務，tcc模式註冊資源在分析資源裏，
*xa/at是在數據源代理註冊，tcc是服務型的模式，不要求代理數據源，因此放在分析資源手段。
tcc註冊資源做兩個事情，
1 本地緩存tcc註解定義的commit/rollback方法，後續分支的commit和rollback使用到
2 註冊到tc，後續tc與rm通訊
！注意區分，資源註冊和分支註冊，資源是參與事務的角色，但此時並不涉及事務，而分支註冊已是事務中，參與者是資源
系列
- 事務框架流程 分析參與框架流程的組件，tm，rm，協調core 完成
- 事務模式 tcc 本文 分3篇，本文是第一篇
- 事務模式at NEXT
- 事務模式xa NEXT
- 預置長事務流程，本人覺得可用性不強，本系列不作分析就是事務模式saga saga是處理超長事務模式，事務分成多段，執行中記錄執行路徑，執行過程遇到異常，根據策略可向前重試，或向後回滾，需要輔助記錄，seata的解決方案
