> 作者：ptti
>
> 來源：[恆生LIGHT雲社群](https://developer.hs.net/thread/1805)

透過前面的文章《[seata入門介紹與seata-service部署與驗證](https://developer.hs.net/thread/1032)》，我們對seata已經有一個大體的認識，並且也瞭解到[seata分散式事務AT模式](https://developer.hs.net/thread/1033)，今天我們介紹SEATA分散式事務框架中TCC事務框架。打算從原理、實際原型演示、推薦的應用場景、注意事項等這幾個維度去介紹TCC分散式事務。

首先介紹一下TCC，關於TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland於2007年發表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。

TCC作為一種與平臺無關的抽象的開放的方案，有眾多廠商有自己的實踐。已知比較流行的有開源框架有ByteTCC, SEATA，恆生電子也有自己的TCC實現。瞭解SEATA TCC原理推薦閱讀以下兩個資料：

SEA他的官方介紹：https://SEATA.io/zh-cn/docs/dev/mode/tcc-mode.html

螞蟻金服相關開發者分享：https://www.bilibili.com/video/BV1pK411s7MS?from=search&seid=10347207598851791940

對於TCC的解釋:

* Try階段：嘗試執行,完成所有業務檢查（一致性）,預留必須業務資源（準隔離性）
* Confirm階段：確認執行真正執行業務，不作任何業務檢查，只使用Try階段預留的業務資源，Confirm操作滿足冪等性。要求具備冪等設計，Confirm失敗後需要進行重試。
* Cancel階段：取消執行，釋放Try階段預留的業務資源
  Cancel操作滿足冪等性Cancel階段的異常和Confirm階段異常處理方案基本上一致。

對TCC的理解概括如下：

* 基於Confirm 與 Cancel任務執行必然成功的假設下，TCC仍然是一個2PC協議。
* 在分散式環境下，它沒有提供一個全域性的鎖的機制去控制資源競爭，僅是約定一個異常時處理回滾操作的流程。

原型演示:

本文涉及demo 基於Springcloud + Feign。採用Spring Boot工程，整合Spring Cloud Feign，業務資料庫採用的Mysql8.0。

1、業務DB初始化，使用相關指令碼構建業務db。![初始化業務db.png](https://developer.hs.net/storage/attachments/2021/12/22/zMNmZrkQEq1K4jtzSjwAfYBHUPzWSa0ghczZcj9X_thumb.png "4383")

2、maven project部署，包含三個業務模組：account使用者中心，order訂單中心，storage庫存中心。

![模組.png](https://developer.hs.net/storage/attachments/2021/12/22/vtbLLatxcytQIUgCSVAKt4HRZEjZNwEBfapUhzpz_thumb.png "4384")

order是整體業務的入口。

![order.png](https://developer.hs.net/storage/attachments/2021/12/22/YPFgvMkb8q8FEI2zQJIO8OjGslaYpJxskB4Se1H0_thumb.png "4385")

關鍵依賴

* spring-cloud-alibaba-SEATA-x.x.x.RELEASE-sources.jar  SEATA與 Spring Cloud 原生元件(Feign, Hystrix …）適配與整合。
* SEATA-all-x.x.x.jar SEATA 的核心業務邏輯。
* SEATA-spring-boot-starter.x.x.x.jar 與spring boot的整合。

業務一致性核心介面

```
OrderTccAction.java
AccountTccAction.java
StorageTccAction.java
```

![核心介面.png](https://developer.hs.net/storage/attachments/2021/12/22/TSKpyynyS6y7I0oKkabrkz0CS3NDqpJXiZ2A3tds_thumb.png "4386")

3、整體邏輯如下圖：

![整體邏輯.png](https://developer.hs.net/storage/attachments/2021/12/22/9SN4c25eLh8ITyf61Qg1iPPFvhjWbAq3GspCB0gd_thumb.png "4387")

4、初始化資料資訊

賬戶餘額表

![賬戶餘額.png](https://developer.hs.net/storage/attachments/2021/12/22/AARq6foDeeqUcB6BL8HmWKNDj2pICQUkLt1TqC7n_thumb.png "4388")

訂單資料表

![訂單表.png](https://developer.hs.net/storage/attachments/2021/12/22/81QSTxTH0M32lQxzIFetYJDOwUVBhxAFQB2D9P6v_thumb.png "4389")

庫存資訊表

![庫存表.png](https://developer.hs.net/storage/attachments/2021/12/22/SybZ8upOZ4Cp7PHEb4ROwhgv2Sc5ZwuykX2UygOD_thumb.png "4390")

場景演示1：演示一次正常下單成功過程

![成功下單.png](https://developer.hs.net/storage/attachments/2021/12/22/YanyMbaPHygWHwdKp7DXKeN2lKAu0qpaZ8SyhYbI_thumb.png "4391")

請求返回正常

![正常返回.png](https://developer.hs.net/storage/attachments/2021/12/22/ZyQ7ZQDUxsiXExqtsqQrdQAIYOQqBzCdlCqtXr6Q_thumb.png "4392")

資料庫符合預期

![z1.png](https://developer.hs.net/storage/attachments/2021/12/22/ThyXiCzLrdadMBlRD6bb9bvBqJmS0wWQ9GvU5vwO_thumb.png "4394")![z2.png](https://developer.hs.net/storage/attachments/2021/12/22/fYywJzOidGVEZwB1sANPTDnDlhusHsvTqZ2bNFRJ_thumb.png "4395")![z3.png](https://developer.hs.net/storage/attachments/2021/12/22/JUjucPkol3epNBGUqo0ENvtPYEn10GZeAX7CsUg4_thumb.png "4393")

場景演示2：演示一次庫存不足下單失敗過程

![庫存不足.png](https://developer.hs.net/storage/attachments/2021/12/22/klRwM16vRlrh9zuPN46Gygh4JmIodeBhD0FMOlaV_thumb.png "4396")

注：撤銷訂單的過程可能是非同步完成；

核心程式碼：

![核心程式碼.png](https://developer.hs.net/storage/attachments/2021/12/22/Iq2p0ElByCnqNYIigSEDa0jM6CTgqXufHoJGA8OQ_thumb.png "4397")

結果演示

![失敗結果.png](https://developer.hs.net/storage/attachments/2021/12/22/1HO6L9zmXrgnq18fvZhLQezgONqK6n5BqqpHGE8K_thumb.png "4398")

資料驗證，訂單並未生成

![失敗資料.png](https://developer.hs.net/storage/attachments/2021/12/22/hYMvpcTilHOo2aozzzgLxSU6u9S8ansikXPhbdHd_thumb.png "4399")

以上，演示完畢，當然可以設計更多場景進行驗證，這裡不再展開。

關於seata的TCC模式的一些注意事項與推薦實踐

1、關於空迴歸，懸掛和冪等問題，目前TCC模式下，業務同學必須自己處理這3個問題。如何設計事務查詢表去解決這3個問題是具有一定的技術難度的。例如採用了一個全域性的靜態的ConcurrentHashMap ResultHolder.map 作為事務查詢表解決了冪等問題，供參考。需要到網上查詢更多相關資料學習。當然SEATA目前已經實現了一個通用的事務查詢表功能，框架有能力自己去解決這3個問題。

2、二階段的動作必須成功：一階段成功後，二階段的Confirm與Cancel 動作必須成功是TCC模式的約定與前提。開發者需要根據自己實際的業務場景，去判斷相關的業務邏輯是放在Try中還是放在Confirm中。   在示例程式碼中存在一個比較典型的業務劃分的方法，即在Try中操作frozen 欄位鎖定賬戶金額/產品庫存，在Confirm中操作used欄位去正式扣款/扣庫存。如果沒有frozen欄位，那麼扣款/扣庫存的動作應該放置於Try方法中而不是Confirm方法中。

3、預設不支援併發多執行緒。

基於SEA他的原始碼分析與實際程式碼驗證；TCC模式本身對多執行緒併發執行支援有限。

如果開闢其他執行緒執行任務呼叫（無論是本地呼叫，還是RPC/HTTP遠端呼叫），不會加入本地全域性事務。

基於此問題，已經在社群有相關實踐經驗的開發者確認，透過自己獲取xId加入到相關執行緒的ThreadLocalMap中就可以把當前執行緒執行的任務join到全域性事務中；

處理了本地呼叫場景的前提下，理論上遠端呼叫的場景不需要再做額外處理，因為框架會在RPC/Http發起之前攔截請求，將相關的全域性事務資訊從Thread中獲取，寫入到請求中。

下面這個專案值得參考[https://github.com/caohdgege/seata-async](https://github.com/caohdgege/seata-async)一下，他一定程度上解決了多執行緒場景的問題，但是尚未驗證。因時間有限，這裡並未進一步確認該方案是否100%準確無誤。

4、TCC無預設資料隔離性。TCC透過約定了一個異常回滾的呼叫流程，僅僅是解決了分散式環境下事務的原子性問題。無論是分散式環境下，還是單機環境下的資料隔離性問題，完全需要業務同學自己考慮。在本Demo中可以看到Try or Confirm方法大多會被@Transactional 關鍵字修飾；單庫的ACID性還需要依賴DB本身提供。

5、二階段（Confirm與Cancel）可能會非同步處理。TCC方案比較適合高併發的業務場景。基於confirm 與 rollback操作必然成功的假設前提，二階段非同步處理會極大提升高峰期業務的效能。比如本demo中的示例，客戶落單後可以先只是凍結賬戶金額，並不直接劃撥款項，等到業務高峰期結束，再約定一個時間（可能時某個定時任務）統一劃撥，從而達到削峰的效果。

到此seata分散式事務TCC模式原理和使用分享完成。

***

想向技術大佬們多多取經？開發中遇到的問題何處探討？如何獲取金融科技海量資源？

[恆生LIGHT雲社群](https://developer.hs.net/)，由恆生電子搭建的金融科技專業社群平臺，分享實用技術乾貨、資源資料、金融科技行業趨勢，擁抱所有金融開發者。

掃描下方小程式二維碼，加入我們！

![](https://developer.hs.net/storage/attachments/2021/12/20/vzjJlveZdvxcz6rUjIBaPMbRK36iL8jCjtMU5h97.png)

seata分散式事務TCC模式介紹及推薦實踐

相關文章