tcc是由支付寶架構師提供的一種柔性解決分布式事務解決方案,主要包括三個步驟:
tcc的關鍵流程如下圖(以下單和扣減庫存為例子)
q: 預生成訂單失敗了,為什麼要通過tcc執行預處理資料回滾?
a: 可能預生成訂單成功,但是介面返回失敗(超時失敗),所以預處理在某些情況下是有預處理資料,需要清理
在整個流程,我們主要需要關注的是cancel失敗和confirm失敗引起的資料不一致現象
tcc服務支援介面失敗重試,所以對tcc暴露的介面都需要滿足冪等性(根據事務id很好滿足)
基於tcc的中心化事務一致性解決方法,各個應用伺服器如果需要感知某次事務是否成功的成本很高,所以對於自身而言進行事務補償成本就會很高.舉個例子:
1⃣️每次成功的執行本應用伺服器的事務以後,都需要把成功執行的事務id記錄
2⃣️繼續confirm或者將confirm完的資料回滾,對使用者都很不友好,特別是需要confirm訂單或者回滾訂單資料
3⃣️可以根據事務開始的時間,並且設計乙個事務超時時間,如果在這個時間範圍以外事務還沒有處理完成,就可以當做這個事務已經失敗,將預處理資料刪除
總體來說,事務補償機制,心智負擔過於沉重.所以只能依賴tcc伺服器的失敗重試機制,如果失敗重試機制不能處理,只能人肉去處理(建議全程人肉,因為同時進行失敗重試和人肉的話,因為如果失敗重試和人肉都在操作同一條資料,還需要考慮這種競爭的場景,對重試次數需要限定)
是否一定需要tcc伺服器?
不一定,可以讓交易鏈路來充當tcc伺服器的角色,但是長期來看,tcc相當於是乙個公用的元件,所以其它地方也需要tcc分布式事務,可以公用這乙個元件(交易鏈路可以完成tcc所能完成的一切操作,把tcc單獨部署乙個服務,僅僅是考慮整個系統的抽象結構和功能復用)
這裡說的預處理,指的是什麼?
在整個分布式事務中預處理的含義其實很廣泛,比如訂單,所謂的預處理就是生成訂單,但是使用者真實是看不到這些訂單的,至於具體實現是在一張新錶中記錄還是在原有的訂單表是加上標記位,具體實現方式由自己統籌考慮(當然還需要考慮記錄事務id);像減庫存這種預處理,可以直接減少原始庫存,再通過另外一張表來記錄這次事務id操作了哪個sku的庫存數量,當然也可以不減少庫存只記錄操作,但是這種方式在計算實際庫存的時候複雜度會提高(需要減掉預處理的那部分)
說說分布式事務
分布式事務說的就是乙個事務的兩個或者多個操作不是在乙個資料庫中進行的，而是在多個資料庫中執行。這個時候，如何保證事務操作的原子性和一致性？舉個支付的例子，支付進行買東西。事務由兩個行為組成，我的購買商品資料表資料 1，支付金額表資料 1。如果這兩個都是在同一庫中，沒啥問題。try catch 事務失...
說說分布式事務 四
預建立訂單失敗 如果實際預建立訂單成功,訂單定時補償機制,定時刪除這部分訂單,不影響資料一致性,下單失敗 預扣減庫存失敗 如果預扣減庫存真實失敗,則下單失敗 訂單由定時補償機制定時刪除,其它應用參照場景4的處理方式,下單失敗 如果實際預扣減庫存成功,參照場景4的處理方式,下單失敗 實際建立訂單失敗 ...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...