實戰(zhàn)！阿里神器 Seata 實現(xiàn) TCC模式 解決分布式事務(wù)，真香！

今天這篇文章介紹一下Seata如何實現(xiàn)TCC事務(wù)模式，文章目錄如下：

?

什么是TCC模式？

• 第一階段：Try（嘗試），主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留 (加鎖，鎖住資源)
• 第二階段：本階段根據(jù)第一階段的結(jié)果，決定是執(zhí)行confirm還是cancel
1. Confirm（確認）：執(zhí)行真正的業(yè)務(wù)（執(zhí)行業(yè)務(wù)，釋放鎖）
2. Cancle（取消）：是預(yù)留資源的取消（出問題，釋放鎖）

①Try 階段

• 完成所有業(yè)務(wù)檢查( 一致性 ) 。
• 預(yù)留必須業(yè)務(wù)資源( 準隔離性 ) 。
• Try 嘗試執(zhí)行業(yè)務(wù)。

②Confirm / Cancel 階段

?

TCC模式的三種類型？

1、通用型 TCC 解決方案

2、異步確保型 TCC 解決方案

3、補償型 TCC 解決方案

“

以上部分內(nèi)容參考自：https://seata.io/zh-cn/blog/tcc-mode-applicable-scenario-analysis.html?utm_source=gold_browser_extension

”

?

TCC事務(wù)模式的落地實現(xiàn)

1、演示場景

1. 客戶端調(diào)用下訂單接口
2. 扣庫存
3. 創(chuàng)建訂單
4. 請求完成

@GlobalTransactional
public?Result?createOrder(Long?productId,Long?num,.....){
????//1、扣庫存
????reduceStorage();
????//2、創(chuàng)建訂單
????saveOrder();
}

• 性能低，鎖定資源時間太長
• 無法解決跨應(yīng)用的事務(wù)

@Transactional
public?boolean?try(){
??//凍結(jié)庫存
??frozenStorage();
??//生成訂單，狀態(tài)為待確認
??saveOrder();
}

“

注意：@Transactional開啟了本地事務(wù)，只要出現(xiàn)了異常，本地事務(wù)將會回滾，同時執(zhí)行第二階段的cancel操作。

”

1. 釋放try操作凍結(jié)的庫存（凍結(jié)庫存-購買數(shù)量）
2. 生成訂單

@Transactional
public?boolean?confirm(){
????//釋放掉try操作預(yù)留的庫存
????cleanFrozen();
????//修改訂單，狀態(tài)為已完成
????updateOrder();
????return?true;
}

“

注意：這里如果返回false，遵循TCC規(guī)范，應(yīng)該要不斷重試，直到confirm完成。

”

1. 恢復(fù)凍結(jié)的庫存（凍結(jié)庫存-購買數(shù)量、庫存+購買數(shù)量）
2. 刪除訂單

@Transactional
public?boolean?cancel(){
????//釋放掉try操作預(yù)留的庫存
????rollbackFrozen();
????//修改訂單，狀態(tài)為已完成
????delOrder();
????return?true;
}

“

注意：這里如果返回false，遵循TCC規(guī)范，應(yīng)該要不斷重試，直到cancel完成。

”

2、TCC事務(wù)模型的三個異常

• 冪等：在執(zhí)行confirm或者cancel之前根據(jù)事務(wù)狀態(tài)表查詢當前全局事務(wù)是否已經(jīng)執(zhí)行過confirm或者cancel方法
• 空回滾：在執(zhí)行cancel之前才能根據(jù)事務(wù)狀態(tài)表查詢當前全局事務(wù)是否已經(jīng)執(zhí)行成功try方法
• 懸掛：在執(zhí)行try方法之前，根據(jù)事務(wù)狀態(tài)表查詢當前全局事務(wù)是否已經(jīng)執(zhí)行過cancel方法

?

Seata整合TCC實現(xiàn)

1、TCC接口定義

1. @LocalTCC：該注解開啟TCC事務(wù)
2. @TwoPhaseBusinessAction：該注解標注在try方法上，其中的三個屬性如下：
1. name：TCC事務(wù)的名稱，必須是唯一的
2. commitMethod：confirm方法的名稱，默認是commit
3. rollbackMethod：cancel方法的名稱，，默認是rollback
3. confirm和cancel的返回值尤為重要，返回false則會不斷的重試。

2、TCC接口實現(xiàn)

“

注意：必須要開啟本地事務(wù)，如上代碼使用@Transactional開啟本地事務(wù)

”

“

注意：1. 開啟本地事務(wù) ?2. 注意返回值，返回false時將會重試

”

3、如何防止TCC模型的三個異常？

1. 在try方法最后使用冪等工具類中的add方法添加值
2. 在confirm、cancel方法中使用冪等工具類中的remove方法移出值
3. 在confirm、cancel方法中使用冪等工具類中g(shù)et方法獲取值，如果為空，則表示已經(jīng)執(zhí)行過了，直接返回true，這樣既防止了冪等，也防止了空回滾。

CREATE?TABLE?`transactional_record`?(
??`id`?bigint(11)?NOT?NULL?AUTO_INCREMENT,
??`xid`?varchar(100)?NOT?NULL,
??`status`?int(1)?DEFAULT?NULL?COMMENT?'1.?try??2?commit?3?cancel?',
??PRIMARY?KEY?(`id`)?USING?BTREE
)?ENGINE=InnoDB?DEFAULT?CHARSET=utf8mb4;

“

其他的字段自己可以擴展

”

1. cancel方法中將當前全局事務(wù)ID記錄到事務(wù)日志表中，狀態(tài)為cancel
2. try方法執(zhí)行資源操作前檢查事務(wù)日志表中當前全局事務(wù)ID是否已經(jīng)是cancel狀態(tài)

4、創(chuàng)建訂單的業(yè)務(wù)方法

5、其他的配置

1. 接口測試
2. 整合nacos
3. 整合feign
4. 整合seata，TCC模式中的配置和AT模式的Seata配置相同

“

注意：一定要配置Seata的事務(wù)組tx-service-group，配置方法見之前的文章。

”