說說分佈式事務(三)

最終一致性(一)

TCC

簡介

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的庫存數量,固然也能夠不減小庫存只記錄操做,可是這種方式在計算實際庫存的時候複雜度會提升(須要減掉預處理的那部分)