GitHub專案地址：seata-spring-boot-demos
一、什么是Seata？
官網地址：https://seata.io
提煉關鍵詞：
特性：
1、一致性（這個是痛點，解決的就是微服務分布式事務一致性的問題）
2、高性能（這個是賣點，如果用了反而拖累整個微服務架構的性能，試問誰還會用呢？）
3、易用性（這個是亮點，大家開發時引入新技術，都希望簡單好用，如果技術太過于復雜，反而會提升使用門檻，嚇跑用戶）
事務模式
- AT （Automatic Transaction，對業務系統無侵入，省去了用的人很多編碼的作業）
- TCC（Try-Confirm-Cancel，對業務系統有侵入，用的時候需要自己寫大量的代碼）
- Saga （Long Live Transaction，長事務解決方案，對業務系統有侵入，同TCC）
- XA （ X/Open 組織提出的分布式事務處理的規范，對業務系統無侵入，只需要DB實作了XA協議即可）
文章推薦：帶你讀透 SEATA 的 AT 模式
這篇文章講的很好，很適合結合著Seata官方檔案細細品讀，下面放幾張文中的關鍵圖
- 每個應用服務對應一個本地資料庫，即database per service；
- 每個應用服務之間互相協作，呼叫介面；
- 每個應用服務執行自己的SQL腳本；
- 每個應用服務執行自己的SQL陳述句時，是基于本地事務的；
- 每個應用服務對應的本地庫中，都存在一個UNDO Log（回滾日志記錄）；
- 每個應用服務實作自己的事務提交，如果有一個事務提交失敗，則全域回滾；
- 發生全域事務回滾時，則每個分支（本地）事務按照UNDO log內容對資料集進行反向補償（反向SQL）
搞懂上圖，需要知道Seata的三個角色概念：
- TC（Trasaction Cordornator，事務協調器）
- TM（Transaction Manager，事務管理器）
- RM （Resource Manager，資源管理器）
其中TC對應的應用服務就是seata-server
TC角色主要用來和TM和RM進行“交流”的，通過rpc（Netty）+服務注冊發現（nacos等），實作與各個微服務模塊之間的通信
其中TM對應的應用服務就是開啟了@GlobalTransactional注解的業務方法所在的微服務模塊，即seata-business-server
TM角色主要定義了全域事務的邊界，用來向TC開啟一個全域事務，拿到全域事務唯一的XID，并在呼叫的微服務之間的背景關系中進行傳遞，同時，該服務還掌握著是否全域提交還是全域回滾的決議權！
TM端呼叫結束，我們接下來看下TC端
執行完后，看下資料庫
全域提交的條件是：各個微服務的分支事務均提交成功；
全域回滾的條件是：只要有一個微服務的分支事務提交失敗，就會觸發整個全域事務的回滾！
其中RM對應的應用服務就是在業務上存在SQL陳述句執行的微服務模塊，如order-server
RM角色主要用來向TC注冊分支事務（保存到seata庫對應的branch_table表中），并上報分支事務提交和回滾的狀態給TC，TC根據分支事務提交和回滾的狀態來驅動TM最終進行全域的提交或全域的回滾；
（關于RM和TC互動的代碼除錯就不放了，下面放幾張和分支事務有關的截圖吧，有問題的可以留言）
庫存服務（RM）對應的初始化商品的庫存記錄如下：
TC分支事務表記錄如下：
庫存服務（RM）在TM開啟全域事務后，執行減庫存操作但事務未提交時的分支事務記錄如下：
庫存服務（RM）在TM開啟全域事務后，執行減庫存操作但事務未提交時的分支回滾記錄如下：
每個分支事務都對應一條undo_log記錄，我們匯出減庫存的log后，查看其內容如下：
最后執行成果后，相應的undo_log記錄會被洗掉，重繪庫存的undo_log表記錄如下：
最終，我們可以看到，水杯的庫存量為：
如果TM發起全域提交，則TC會分別呼叫各個微服務，并對各個RM中的undo_log表中的XID記錄進行異步洗掉；
如果TM發起全域回滾，則TC會分別呼叫各個微服務，并對各個RM中的undo_log表中的XID記錄進行反向SQL，恢復事務操作前的資料；
二、Seata原始碼編譯
未完待續,.................
三、Seata服務引數配置
未完待續,.................
四、Seata服務啟動
未完待續,.................
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/162517.html
標籤：其他
上一篇：Cloud-Admin首個基于Spring Cloud微服務化開發平臺原始碼分享
下一篇：一圖看懂互聯網各職位都是干啥的