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的庫存數量,當然也可以不減少庫存只記錄操作,但是這種方式在計算實際庫存的時候複雜度會提高(需要減掉預處理的那部分)
TCC 分布式事物最終一致性
tcc是由支付寶架構師提供的一種柔性解決分布式事務解決方案,主要包括三個步驟 tcc的關鍵流程如下圖 以下單和扣減庫存為例子 q 預生成訂單失敗了,為什麼要通過tcc執行預處理資料回滾?a 可能預生成訂單成功,但是介面返回失敗 超時失敗 所以預處理在某些情況下是有預處理資料,需要清理 在整個流程,我...
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...