二、Seata學習

2.1、Seata介紹

2.1.1、Seata背景

Seata是 2019 年 1 月份螞蟻金服和阿里巴巴共同開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務，為用戶打造一站式的分布式解決方案
官網地址：http://seata.io/，其中的檔案、播客中提供了大量的使用說明、原始碼分析

2.1.2、Seata架構

Seata事務管理中有三個重要的角色：
- TC（Transaction Coordinator）- 事務協調者：維護全域和分支事務的狀態，協調全域事務提交或回滾
- TM（Transaction Manager）- 事務管理器：定義全域事務的范圍、開始全域事務、提交或回滾全域事務
- RM（Reasource Manager）- 資源管理器：管理分支事務處理的資源，與TC交談以注冊分之十五和報告分支事務的狀態，并驅動分支事務提交或回滾
整體架構如下圖所示
Seata基于上述架構提供了四種不同的分布式事務解決方案
- XA模式：強一致性分階段事務模式，犧牲了一定的可用性，無業務入侵（CP模式）
- TCC模式：最終一致的分階段事務模式，有業務侵入（AP模式）
- AT模式：最終一致的分階段事務模式，無業務侵入，也是Seata的默認模式（AP模式）
- SAGA模式：長事務模式，有業務侵入（AP模式）
無論那種方案，都離不開TC，也就是事務的協調者

2.2、部署TC服務器

Seata的TC服務器架構

2.2.1、下載

首先我們需要到官網下載seata-server包，地址如下所示
- http??/seata.io/zh-cn/blog/download.html
本人下載的是1.4.2版本，如下所示

2.2.2、解壓

在非中文目錄解壓這個壓縮包，其目錄結構如下所示

2.2.3、修改配置

修改conf目錄下的registry.conf檔案，內容如下所示

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"

  nacos {
    # seata tc 服務注冊到 nacos的服務名稱，可以自定義
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "DEFAULT_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

只需要按照上面的內容修改部分即可

2.2.4、在nacos添加配置

特別注意，為了讓TC服務的集群可以共享配置，我們選擇了nacos作為統一配置中心，因此服務端組態檔seataServer.properties檔案需要在nacos中配好
格式如下

配置內容如下

# 資料存盤方式，db代表資料庫
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?serverTimezone=Asia/Shanghai&useSSL=false
store.db.user=root
store.db.password=123
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事務、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000

# 客戶端與服務端傳輸方式
transport.serialization=seata
transport.compressor=none
# 關閉metrics功能，提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898

其中的資料庫地址、用戶名、密碼等請自行修改

2.2.5、創建資料庫表

這里需要特別提醒的是：TC服務在管理分布式事務的時候，需要記錄事務相關資料到資料庫，需要提前創建好這些表

新建一個名為seata的資料庫

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- 分支事務表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table`  (
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `status` tinyint(4) NULL DEFAULT NULL,
  `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime(6) NULL DEFAULT NULL,
  `gmt_modified` datetime(6) NULL DEFAULT NULL,
  PRIMARY KEY (`branch_id`) USING BTREE,
  INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

-- ----------------------------
-- 全域事務表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `status` tinyint(4) NOT NULL,
  `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `timeout` int(11) NULL DEFAULT NULL,
  `begin_time` bigint(20) NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`xid`) USING BTREE,
  INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
  INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

SET FOREIGN_KEY_CHECKS = 1;

這些表主要記錄全域事務、分支事務、全域鎖資訊

2.2.6、啟動TC服務

進入解壓后的斌目錄，運行其中的seata-server.bat即可
- PS：如果啟動不成功且報錯資訊為：seata Unrecognized VM option ‘CMSParallelRemarkEnabled ......，則需要更改JDK版本，本地JDK版本太高（可參考CSND：同一臺電腦安裝多個版本JDK，如何切換JDK版本_wq379143763的博客-CSDN博客_切換jdk版本）
- 修改后還是啟動不成功的話，且報錯資訊為Error occurred during initialization of VM Could not reserve enough space for object heap，那就是顯示當前運行記憶體不足，關掉一些后臺不需要的應用即可
啟動成功后，seata-server應該已經注冊到nacos注冊中心了
打開瀏覽器，訪問nacos地址
- http://localhost:8848/nacos
然后進入服務串列頁面，可以看到seata-tc-server的資訊

2.3、微服務整合Seata

以之前匯入的工程中的oder-service為例

2.3.1、引入依賴

在order-service中引入依賴

<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本較低，1.3.0，因此排除--> 
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

2.3.2、配置TC地址

在order-service中的application.yml中，配置TC服務資訊，通過注冊中心nacos，結合服務名稱獲取TC地址

seata:
  registry: # TC服務注冊中心的配置，微服務根據這些資訊去注冊中心獲取tc服務地址
    type: nacos # 注冊中心型別 nacos
    nacos:
      server-addr: 127.0.0.1:8848 # nacos地址
      namespace: "" # namespace，默認為空
      group: DEFAULT_GROUP # 分組，默認是DEFAULT_GROUP
      application: seata-tc-server # seata服務名稱
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事務組名稱
  service:
    vgroup-mapping: # 事務組與cluster的映射關系
      seata-demo: GZ

微服務是如何根據這些配置尋找TC的地址呢？
- 我們知道注冊到Nacos的微服務，確定一個具體的實體需要四個資訊
  - ①、namespace：命名空間
  - ②、group：分組
  - ③、application：服務名稱
  - ④、cluster：集群名
- 以上四個資訊，在上面的yaml檔案中都能找到，下圖是Nacos查詢具體實體的流程圖
- 其中，namespace為空，就是默認的public
- 結合起來，TC服務在nacos上的資訊就是
  - pulic@DEFAULT_GROUP@seata-tc-server@GZ，這樣就能確定TC服務集群了，然后就可以去nacos拉取對于的實體資訊

2.3.3、其他服務的配置

其他兩個微服務也都參考上面的order-service的配置步驟，完全一樣

2.3.4、測驗服務是否正常啟動

正常啟動界面
- nacos
- seata
- IDEA
例外啟動
- NettyClientChannelManager : 0304 register RM failed或者0101 can not connect
- 我個人這里的原因是不知道為什么雙擊啟動seata后，seata在nacos里面注冊的IP地址指向的不是當前局域網內的IP，所以導致連接失敗
解決方式
- 不選擇雙擊啟動，選擇命令列啟動
  - seata-server.bat -h 本地ip/127.0.0.1
  - 具體原因個人暫時沒有找到
- 不過奇怪的是我在指定ip之后，后續關閉再直接雙擊或者直接使用seata-server.bat命令的時候，nacos中注冊的seata服務的ip會自己注冊到本地ip，只有第一次雙擊不指定ip的時候會注冊到其他ip（應該是本機對外的IP）

2.4、XA模式的概念與使用

2.4.1、XA模式的概念

XA 規范是 X/Open 組織定義的分布式事務處理（DTP，Distributed Transaction Processing）標準，XA 規范描述了全域的TM與區域的RM之間的介面，幾乎所有主流的關系型資料庫都對 XA 規范提供了支持

2.4.2、兩階段式提交

Two Pharse Commit

XA 是規范，目前主流資料庫都實作了這種規范，實作的原理都是基于兩階段提交
正常情況
例外情況
一階段
- 事務協調者通知每個事務參與者執行本地事務
- 本地事務執行完后報告事務執行狀態給是事務協調者，此時事務不提交，繼續持有資料庫鎖
二階段
- 事務協調者基于一階段的報告來判斷下一步操作
  - 如果一階段都成功，則通知所有事務參與者，提交事務
  - 如果一階段任意一個參與者失敗，則通知所有事務參與者回滾事務

2.4.3、Seata的XA模型

Seata對原始的XA模式做了簡單的封裝和改造，以適應自己的事務模型，基本架構如下圖所示
RM一階段的作業
- ①、注冊分支事務到TC
- ②、執行分支業務sql但不提交
- ③、報告執行狀態到TC
TC二階段的作業
- 檢測各個分支事務的執行狀態
  - a. 如果都成功，則通知所有RM提交事務
  - b. 如果有失敗，則通知所有RM回滾事務
RM二階段的作業
- 接收TC指令，提交或回滾事務

2.4.4、XA模式的優缺點

XA模式的優點
- 事務的強一致性，滿足ACID原則
- 常用關系型資料庫都支持，實作簡單，并且沒有代碼侵入（業務侵入）
XA模式的缺點
- 因為一階段要鎖定資料庫資源，等待二階段結束才釋放，性能較差
- 依賴關系型資料實作事務

2.4.5、實作XA模式（CP）

Seata的starter已經完成了XA模式的自動裝配，實作非常簡單，步驟如下所示
- ①、每一個分支事務都需要配置為XA模式，否則默認使用AT模式
  - ```
  seata:
    data-source-proxy-mode: XA
```
- ②、給發起全域事務的入口方法添加@GlobalTransactional注解，本例中是OrderServiceImpl中的create方法
重啟服務并測驗
- 重啟order-service，再次測驗，發現無論怎樣，三個微服務都能成功回滾

2.5、AT模式的概念與使用（AP）

2.5.1、AT模式簡介

AT模式同樣是分階段提交的事務模型，不過卻彌補了XA模型中資源鎖定周期過長的缺陷

2.5.2、Seata的AT模型

AT模型的基本流程圖如下所示
RM階段一的作業
- ①、注冊分支事務
- ②、記錄undo-log（資料快照）
- ③、執行業務sql并提交
- ④、報告事務狀態
RM階段二提交時的作業
- 洗掉undo-log中的相關資料
RM階段二回滾時的作業
- 根據undo-log恢復資料到更新前

2.5.3、流程梳理

接下來我們以一個真實的業務來梳理一下AT模式的原理
- 比如，現在有一個資料庫表，記錄用戶余額
  - id money
    
    1 100
- 其中一個分支業務要執行的SQL為
  - ```
  update tb_account set money = money - 10 where id = 1
```
AT模式下，當前分支事務的執行流程如下
- 一階段
  - ①、TM發起并注冊全域事務到TC
  - ②、TM呼叫分支事務
  - ③、分支事務準備執行業務SQL
  - ④、RM攔截業務SQL，根據where條件查詢原始資料，形成快照
    - ```
    {
        "id": 1, "money": 100
    }
```
- ⑤、RM執行業務SQL，提交本地事務，釋放資料庫鎖，此時money = 90
- ⑥、RM報告本地事務狀態給TC
- 二階段
  - ①、TM通知TC事務結束
  - ②、TC檢查分支事務狀態
    - a. 如果都成功，則立即洗掉快照
    - b. 如果有分支事務失敗，需要回滾，讀取快照資料，將快斬訓復到資料庫，此時資料庫再次恢復為100
流程圖

id	money
1	100

2.5.4、AT和XA的區別

AT模式與XA模式最大的區別是什么？
- ①、XA模式一階段不提交事務，鎖定資源；AT模式一階段直接提交，不鎖定資源，AT模式的可用性比XT模式更好
- ②、XA模式依賴資料庫機制實作回滾；AT模式利用資料快照實作資料回滾
- ③、XA模式強一致；AT模式弱一致（最終一致），AT模式一致性比XA更差

2.5.5、AT的臟寫問題

在多執行緒并發訪問AT模式的分布式事務的時候，有可能出現臟寫問題，如下圖所示
解決思路就是引入全域鎖，如下圖所示
還有一個非seata事務的臟寫問題，需要依靠after-image更新后快照來進行臟寫校驗

2.5.6、AT模式的優缺點

AT模式的優點
- 一階段完成直接提交事務，釋放資料庫資源，性能比較好
- 利用全域鎖實作讀寫隔離
- 沒有代碼侵入，框架自動完成回滾和提交
AT模式的缺點
- 兩階段之間屬于軟狀態，屬于最終一致
- 框架的快照功能會影響性能，但比XA模式要好很多

2.5.7、實作AT模式

AT模式中的快照生成、回滾等動作都是由框架自動完成，沒有任何代碼侵入，因此實作十分簡單

①、只不過，AT模式需要一張表來記錄全域鎖、另一張表來記錄資料塊找undo_log

匯入全域鎖表lock_tbale到TC服務關聯的資料庫（seata）

-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',
  `rollback_info` longblob NOT NULL COMMENT 'rollback info',
  `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',
  `log_created` datetime(6) NOT NULL COMMENT 'create datetime',
  `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;

-- ----------------------------
-- Records of undo_log
-- ----------------------------

匯入資料記錄表undo_log到微服務關聯的資料庫

-- ----------------------------
-- Table structure for lock_table
-- ----------------------------
DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table`  (
  `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `branch_id` bigint(20) NOT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`row_key`) USING BTREE,
  INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;


SET FOREIGN_KEY_CHECKS = 1;

②、修改application.yml檔案，將事務模式修改為AT模式即可
- ```
seata:
  data-source-proxy-mode: AT # 默認就是AT
```
③、重啟服務并測驗
- 事務回滾操作也能正常執行，本例目前暫時看不出來有什么變化；（不過可以打斷點之后，查看資料庫中的資料變化）

2.6、TCC模式的概念與使用

2.6.1、TCC模式簡介

TCC模式與AT模式非常相似，每階段都是獨立事務，不同的是TCC通過人工編碼來實作資料恢復，需要實作三個方法
- Try：資源的檢測和預留
- Confirm：完成資源操作業務；要求Try成功Confirm一定要能成功
- Cancel：預留資源釋放，可以理解為try的反向操作

2.6.2、流程分析

舉例，一個扣減用戶余額的業務，假設賬戶A原來余額是100，需要余額扣減30元
- 階段一（Try）：檢查余額是否充足，如果充足則凍結金額增加30元，可用余額扣除30元、
  - 初始余額
  - 余額充足，可以凍結
  - 此時，總金額 = 凍結金額 + 可用金額，數量依然是100不變，事務直接提交無需等待其他事務
- 階段二（Confirm）：假如要提交（Confirm），則凍結金額扣減30
  - 確認可以提交，不過之前可用金額已經扣減過了，這里只要請求凍結金額就好了
  - 此時，總金額 = 凍結金額 + 可用金額 = 70
- 階段二（Cancel）：如果要回滾（Cancel），則凍結金額扣減30，可用余額增加三十
  - 需要回滾，那么就釋放凍結金額，恢復可用金額

2.6.3、Seata的TCC模型

Seata中的TCC模型依然延續之前的事務框架，如下圖所示

2.6.4、TCC的優缺點

TCC模式的每個階段的作用
- Try：資源檢查和預留
- Confirm：業務執行和提交
- Cancel：預留資源的釋放
TCC的優點
- 一階段完成直接提交事務，釋放資料庫資源，性能好
- 相比AT模型，無需生成快照，無需使用全域鎖，性能最強
- 不依賴資料庫事務，而是依賴補償操作，可以用于非事務型資料庫
TCC的缺點
- 有代碼侵入，需要認為撰寫Try、Confirm、和Cancel介面，編碼成本比較高
- 軟狀態，事務是最終一致

2.6.5、事務懸掛和慷訓滾

慷訓滾

當某分支事務的Try階段阻塞的時候，可能導致全域事務超時而觸發二階段的Cancel操作，在未執行Try操作時，先執行了cancel操作，這就是回滾，如下圖所示
執行Cancel操作時，應當判斷Try是否已經執行，如果尚未執行，則應該慷訓滾

事務懸掛

對于已經慷訓滾的業務，之前被阻塞的Try操作恢復，繼續執行Try，就永遠不可能confirm和cancel，事務一直處于中間狀態，這就是事務懸掛
執行try操作的時候，應當判斷cancel是否已經執行過了，如果已經執行，應當阻止慷訓滾后的try操作，避免懸掛

2.6.6、實作TCC模式

①、思路分析

既然要凍結金額，那么就需要一張凍結金額的表資料

/*
 Navicat Premium Data Transfer

 Source Server         : local
 Source Server Type    : MySQL
 Source Server Version : 50622
 Source Host           : localhost:3306
 Source Schema         : seata_demo

 Target Server Type    : MySQL
 Target Server Version : 50622
 File Encoding         : 65001

 Date: 23/06/2021 16:23:20
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for account_freeze_tbl
-- ----------------------------
DROP TABLE IF EXISTS `account_freeze_tbl`;
CREATE TABLE `account_freeze_tbl`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
  `state` int(1) NULL DEFAULT NULL COMMENT '事務狀態，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of account_freeze_tbl
-- ----------------------------

SET FOREIGN_KEY_CHECKS = 1;

其中
- xid：是全域事務的id
- freeze_money：用來記錄用戶凍結金額
- state：用來記錄事務狀態
那此時，我們的業務該怎么做呢？
- Try業務：
  - 記錄凍結金額和事務狀態到account_freeze表
  - 扣減account表可用金額
- Confirm業務
  - 根據xid洗掉account_freeze表的凍結記錄
- Cancel業務
  - 修改account_freeze表，凍結金額為0，state為2
  - 修改account表，恢復可用金額
- 如何判斷是否慷訓滾？
  - cancel業務中，根據xid查詢account_freeze，如果為null則說明try還沒做，需要慷訓滾
- 如何避免業務懸掛？
  - try業務中，根據xid查詢account_freeze ，如果已經存在則證明Cancel已經執行，拒絕執行try業務
接下來，我們改造account-service，利用TCC實作余額扣減功能

②、宣告TCC介面

TCC的Try、Confirm、Cancel方法都需要在介面中基于注解來宣告

在account-service專案中的cn.coolman.account.service包中新建一個介面，宣告TCC三個介面，如下所示

package cn.coolman.account.service;

import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;

/**
 * TCC 業務介面
 */
@LocalTCC  //標記為TCC業務介面
public interface AccountTCCService {

    /**
     * 資源預留
     *
     * 從用戶賬戶中扣款 (Try方法)
     */
    @TwoPhaseBusinessAction(name="deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                // @BusinessActionContextParameter :  這個注解的作用就是可以讓其他兩個方法也可以獲取到該引數
                @BusinessActionContextParameter(paramName = "money") int money
                );

    /**
     * 提交資料
     *
     * 提交介面（Confirm方法）
     */
    boolean confirm(BusinessActionContext actionContext);

    /**
     * 回滾
     *
     * 回滾介面（Cancel介面）
     */
    boolean cancel(BusinessActionContext actionContext);
}

③、撰寫實作類

package cn.coolman.account.service.impl;


import cn.coolman.account.entity.AccountFreeze;
import cn.coolman.account.mapper.AccountFreezeMapper;
import cn.coolman.account.mapper.AccountMapper;
import cn.coolman.account.service.AccountTCCService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class AccountTCCServiceImpl implements AccountTCCService  {

    @Autowired(required = false)
    private AccountMapper accountMapper;

    @Autowired(required = false)
    private AccountFreezeMapper freezeMapper;


    /**
     * 資源預留
     *
     * 從用戶賬戶中扣款 (Try方法)
     */
    @Override
    @Transactional
    public void deduct(String userId, int money) {
        //獲取全域事務ID
        String xid = RootContext.getXID();

        // 如果該事務執行過cancel，無需執行try方法
        // 判斷凍結金額表，該事務記錄余額為0，且為cancel狀態，代表該事務執行過cancel方法
        AccountFreeze dbAccountFreeze = freezeMapper.selectById(xid);
        if (dbAccountFreeze != null && dbAccountFreeze.getFreezeMoney().equals(0)
            && dbAccountFreeze.getState().equals(AccountFreeze.State.CANCEL)
        ) {
            //該事務執行過cancel方法，無需執行try方法
            return;
        }

        //先扣減原賬戶余額
        accountMapper.deduct(userId, money);

        //再凍結金額
        AccountFreeze accountFreeze = new AccountFreeze();
        accountFreeze.setXid(xid);
        accountFreeze.setUserId(userId);
        accountFreeze.setFreezeMoney(money);
        accountFreeze.setState(AccountFreeze.State.TRY);

        freezeMapper.insert(accountFreeze);
    }

    /**
     * 提交資料
     *
     * 提交介面（Confirm方法）
     */
    @Override
    @Transactional
    public boolean confirm(BusinessActionContext actionContext) {
        String xid = actionContext.getXid();
        // 洗掉該凍結記錄
        int row = accountMapper.deleteById(xid);

        return row > 0;
    }

    /**
     * 回滾
     *
     * 回滾介面（Cancel介面）
     */
    @Override
    @Transactional
    public boolean cancel(BusinessActionContext actionContext) {
        //獲取全域事務ID
        String xid = actionContext.getXid();

        // 根據全域事務ID查詢凍結金額記錄
        AccountFreeze accountFreeze = freezeMapper.selectById(xid);

        // 獲取賬戶和凍結金額資訊
        String userId = (String) actionContext.getActionContext("userId");

        // 如果該全域事務不存在凍結金額記錄，則判斷 該事務沒有執行try方法
        if (accountFreeze == null) {
            //如果沒有執行try，但執行了cancel，往凍結金額表插入cancel凍結金額
            AccountFreeze accountFreezeNew = new AccountFreeze();
            accountFreezeNew.setXid(xid);
            accountFreezeNew.setUserId(userId);
            accountFreezeNew.setFreezeMoney(0);
            accountFreezeNew.setState(AccountFreeze.State.CANCEL);

            freezeMapper.insert(accountFreezeNew);
            return true;
        }
        Integer freezeMoney = accountFreeze.getFreezeMoney();

        // 恢復原賬戶表余額
        accountMapper.refund(userId, freezeMoney);

        // 修改凍結金額表，金額設定為0，狀態設定cancel
        accountFreeze.setFreezeMoney(0);
        accountFreeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(accountFreeze);
        return count > 0;
    }
}

經過測驗，也可以發現無論怎樣，事務都會成功回滾（想具體查看其中的流程，打斷點，然后，分別查看全域鎖表和凍結表）

2.7、SAGA模式的概念與使用

2.7.1、Saga概念

Saga 模式是 Seata 即將開源的長事務解決方案，將由螞蟻金服主要貢獻
- 其基礎理論是Hector & Kenneth 在1987年發表的論文Sagas
Seata官網對Saga的指南：https://seata.io/zh-cn/docs/user/saga.html

2.7.2、SAGA模式的原理

在Saga模式下，分布式事務內有多個參與者，每一個參與者都是一個沖正補償服務，需要用戶根據業務常見實作其正向操作和逆向回滾操作
分布式事務執行程序中，依次執行各參與者的正向操作，如果所有正向操作均成功，那么分布式事務提交，如果任何一個正向操作執行失敗，那么分布式事務會退回去執行前面各參與者的逆向回滾操作，回滾已提交的參與者，使分布式事務回到初始狀態
Saga也分為兩個階段
- 一階段：直接提交本地事務
- 二階段：成功則什么都不做，失敗則通過撰寫補償業務來回滾

2.7.3、SAGA模式的優缺點

優點
- ①、事務參與者可以基于事件驅動實作異步呼叫，吞吐量高
- ②、一階段直接提交事務，無鎖，性能好
- ③、不用撰寫TCC中的三個階段，實作簡單
缺點
- ①、軟狀態持續時間不確定，時效性差
- ②、沒有鎖，沒有事務隔離，會有臟寫

2.8、四種模式對比

如下圖所示

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/499609.html

標籤：Java

上一篇：講透JAVA Stream的collect用法與原理，遠比你想象的更強大

下一篇：java如何獲取執行緒id呢？

02-分布式事務之Seata入門