分布式事務TCC及相關介紹

一、柔性事務的模式：冪等操作、可補償操作、可查詢操作和tcc操作

1、可查詢操作：為了保證操作的可查詢，需要對於每乙個服務的每一次呼叫都有乙個全域性唯一的標識，可以是業務單據號（如訂單號）、也可以是系統分配的操作流水號（如支付記錄流水號）。除此之外，操作的時間資訊也要有完整的記錄。

2、冪等操作：冪等性，其實是乙個數學概念。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。也就是說，同乙個方法，使用同樣的引數，呼叫多次產生的業務結果與呼叫一次產生的業務結果相同。

冪等操作的實現方式有多種，如在系統中快取所有的請求與處理結果、檢測到重複操作後，直接返回上一次的處理結果等。

3、可補償操作：比如，在呼叫積分服務給積分帳戶增加積分操作執行之後，操作執行之後，經過分布式事務協調，最終決定回滾整個事務，那麼就需要提供乙個呼叫積分服務給積分帳戶扣減積分的操作。

4、tcc操作：try-confirm-cancel

try: 嘗試執行業務

完成所有業務檢查(一致性) 預留必須業務資源(準隔離性)

confirm:確認執行業務

真正執行業務不作任何業務檢查只使用try階段預留的業務資源 confirm操作要滿足冪等性

cancel: 取消執行業務

釋放try階段預留的業務資源，cancel操作要滿足冪等性

這種型別和可補償操作類似，就是提供一種提交和回滾的機制。是一種典型的兩階段型別的操作。這裡說的兩階段型別操作並不是指2pc，他和2pc還是有區別的。

二、tcc與2pc協議比較　　

tcc位於業務服務層而非資源層

tcc沒有單獨的準備(prepare)階段,try操作兼備資源操作與準備能力

try操作可以靈活選擇業務資源的鎖定粒度(以業務定粒度)

tcc有較高開發成本

所謂的tcc程式設計模式，也是兩階段提交的乙個變種。tcc就是通過**人為實現了兩階段提交，不同的業務場景所寫的**都不一樣，複雜度也不一樣，因此，這種模式並不能很好地被復用　　

三、tcc事務是為了解決應用拆分帶來的跨應用業務操作原子性的問題

try：預留業務資源：把多個應用中的業務資源預留和鎖定住，為後續的確認打下基礎

confirm：確認執行業務操作：在try操作中涉及的所有應用均成功之後進行確認，使用預留的業務資源

cancel：取消執行業務操作：當try操作中涉及的所有應用沒有全部成功，需要將已成功的應用進行取消(即rollback回滾)

四、乙個案例理解tcc　　

賬務拆分的業務場景如下，分別位於三個不同分庫的帳戶abc，a和b一起向c轉帳共80元。

1、try：嘗試執行業務。

完成所有業務檢查(一致性)：檢查a、b、c的帳戶狀態是否正常，帳戶a的餘額是否不少於30元，帳戶b的餘額是否不少於50元。

預留必須業務資源(準隔離性)：帳戶a的凍結金額增加30元，帳戶b的凍結金額增加50元，這樣就保證不會出現其他併發程序扣減了這兩個帳戶的餘額而導致在後續的真正轉帳操作過程中，帳戶a和b的可用餘額不夠的情況。

2、confirm：確認執行業務。

真正執行業務：如果try階段帳戶a、b、c狀態正常，且帳戶a、b餘額夠用，則執行帳戶a給賬戶c轉賬30元、帳戶b給賬戶c轉賬50元的轉帳操作。

不做任何業務檢查：這時已經不需要做業務檢查，try階段已經完成了業務檢查。

只使用try階段預留的業務資源：只需要使用try階段帳戶a和帳戶b凍結的金額即可。

3、cancel：取消執行業務

釋放try階段預留的業務資源：如果try階段只有部分成功，比如帳戶a的餘額夠用，且凍結相應金額成功，帳戶b的餘額不夠而凍結失敗，則需要對帳戶a做cancel操作，將帳戶a被凍結的金額解凍掉。