https://blog.csdn.net/u010412301/article/details/78410933

簡介

TCC是由支付寶架構師提供的一種柔性解決分散式事務解決方案,主要包括三個步驟:

TCC流程

TCC的關鍵流程如下圖(以下單和扣減庫存為例子)

Q: 預生成訂單失敗了,為什麼要通過TCC執行預處理資料回滾?

A: 可能預生成訂單成功,但是介面返回失敗(超時失敗),所以預處理在某些情況下是有預處理資料,需要清理

TCC異常場景

在整個流程,我們主要需要關注的是cancel失敗和confirm失敗引起的資料不一致現象

注意事項

1. TCC

   服務支援介面失敗重試,所以對TCC暴露的介面都需要滿足冪等性(根據事務Id很好滿足)

2. 基於TCC的中心化事務一致性解決方法,各個應用伺服器如果需要感知某次事務是否成功的成本很高,所以對於自身而言進行事務補償成本就會很高.舉個例子:

1⃣️每次成功的執行本應用伺服器的事務以後,都需要把成功執行的事務Id記錄 
2⃣️繼續confirm或者將confirm完的資料回滾,對使用者都很不友好,特別是需要confirm訂單或者回滾訂單資料 
3⃣️可以根據事務開始的時間,並且設計一個事務超時時間,如果在這個時間範圍以外事務還沒有處理完成,就可以當做這個事務已經失敗,將預處理資料刪除 
總體來說,事務補償機制,心智負擔過於沉重.所以只能依賴TCC

後記

1. 是否一定需要TCC伺服器? 
   不一定,可以讓交易鏈路來充當TCC伺服器的角色,但是長期來看,TCC相當於是一個公用的元件,所以其它地方也需要TCC分散式事務,可以公用這一個元件(交易鏈路可以完成TCC所能完成的一切操作,把TCC單獨部署一個服務,僅僅是考慮整個系統的抽象結構和功能複用)

2. 這裡說的預處理,指的是什麼? 
   在整個分散式事務中預處理的含義其實很廣泛,比如訂單,所謂的預處理就是生成訂單,但是使用者真實是看不到這些訂單的,至於具體實現是在一張新表中記錄還是在原有的訂單表是加上標記位,具體實現方式由自己統籌考慮(當然還需要考慮記錄事務Id);像減庫存這種預處理,可以直接減少原始庫存,再通過另外一張表來記錄這次事務Id操作了哪個Sku的庫存數量,當然也可以不減少庫存只記錄操作,但是這種方式在計算實際庫存的時候複雜度會提高(需要減掉預處理的那部分)