分佈式事務(2）---TCC原理

分佈式事務(2)---TCC原理

上篇講過有關2PC和3PC理論知識，博客：分佈式事務(1)---2PC和3PC理論

個人理解：2PC、3PC還有TCC都蠻類似的。3PC大體是把2PC的第一階段拆分紅了兩個階段，而TCC我感受是把2PC的第二階段拆分紅了兩個階段。

1、概念

一、概念

TCC又稱補償事務。其核心思想是："針對每一個操做都要註冊一個與其對應的確認和補償（撤銷操做）"。它分爲三個操做：

一、Try階段：主要是對業務系統作檢測及資源預留。
二、Confirm階段：確認執行業務操做。
三、Cancel階段：取消執行業務操做。

TCC對應 Try、Confirm、Cancel 三種操做能夠理解成關係型數據庫事務的三種操做：DML、Commit、Rollback。

在一個跨應用的業務操做中

Try：Try操做是先把多個應用中的業務資源預留和鎖定住，爲後續的確認打下基礎，相似的，DML操做要鎖定數據庫記錄行，持有數據庫資源。

Confirm：Confirm操做是在Try操做中涉及的全部應用均成功以後進行確認，使用預留的業務資源，和Commit相似；

Cancel：Cancel則是當Try操做中涉及的全部應用沒有所有成功，須要將已成功的應用進行取消(即Rollback回滾)。其中Confirm和Cancel操做是一對反向業務操做。

TCC的具體原理圖如（盜圖）:

從圖中咱們能夠明顯看到Confirm和Cancel操做是一對反向業務操做 即要try返回成功執行Confirm,要麼try返回失敗執行Cancel操做。

分佈式事務協調者：分佈式事務協調者管理控制整個業務活動，包括記錄維護TCC全局事務的事務狀態和每一個從業務服務的子事務狀態，並在業務活動提交時確認全部的TCC型

操做的confirm操做，在業務活動取消時調用全部TCC型操做的cancel操做。

二、舉例

例子：A服務轉30塊錢、B服務轉50塊錢，一塊兒到C服務上。

Try：嘗試執行業務。完成全部業務檢查(一致性)：檢查A、B、C的賬戶狀態是否正常，賬戶A的餘額是否很多於30元，賬戶B的餘額是否很多於50元。預留必須業務資源

(準隔離性)：賬戶A的凍結金額增長30元，賬戶B的凍結金額增長50元，這樣就保證不會出現其餘併發進程扣減了這兩個賬戶的餘額而致使在後續的真正轉賬操做過程當中，

賬戶A和B的可用餘額不夠的狀況。

Confirm：確認執行業務。真正執行業務：若是Try階段賬戶A、B、C狀態正常，且賬戶A、B餘額夠用，則執行賬戶A給帳戶C轉帳30元、賬戶B給帳戶C轉帳50元的轉賬

操做。 這時已經不須要作任何業務檢查，Try階段已經完成了業務檢查。只使用Try階段預留的業務資源：只須要使用Try階段賬戶A和賬戶B凍結的金額便可。

Cancel：取消執行業務釋放Try階段預留的業務資源：若是Try階段部分紅功，好比賬戶A的餘額夠用，且凍結相應金額成功，賬戶B的餘額不夠而凍結失敗，則須要

對賬戶A作Cancel操做，將賬戶A被凍結的金額解凍掉。

三、TCC和2PC比較

2PC是資源層面的分佈式事務，強一致性，在兩階段提交的整個過程當中，一直會持有資源的鎖。

XA事務中的兩階段提交內部過程是對開發者屏蔽的，事務管理器在兩階段提交過程當中，從prepare到commit/rollback過程當中，資源實際上一直都是被加鎖的。

若是有其餘人須要更新這兩條記錄，那麼就必須等待鎖釋放。

TCC是業務層面的分佈式事務，最終一致性，不會一直持有資源的鎖。

個人理解就是當執行try接口的時候，已經把所需的資源給預扣了，好比上面舉例的A服務已經預扣30元，B服務已經預扣50元，它是由try接口實現，這樣就保證不會

出現其餘併發進程扣減了這兩個賬戶的餘額而致使在後續的真正轉賬操做過程當中，賬戶A和B的可用餘額不夠的狀況，同時保證不會一直鎖住整個資源。（核心點應該就在這）

TCC中的兩階段提交併無對開發者徹底屏蔽，也就是說從代碼層面，開發者是能夠感覺到兩階段提交的存在。

一、try過程的本地事務，是保證資源預留的業務邏輯的正確性。

二、confirm/cancel執行的本地事務邏輯確認/取消預留資源，以保證最終一致性，也就是所謂的補償型事務。

因爲是多個獨立的本地事務，所以不會對資源一直加鎖。

總的來說

TCC 實質上是應用層的2PC()，比如把 XA 兩階段提交那種在數據資源層作的事務管理工做提到了數據應用層。

2PC是資源層面的分佈式事務，是強一致性，在兩階段提交的整個過程當中，*一直會持有資源的鎖*。

TCC是業務層面的分佈式事務，最終一致性，*不會一直持有資源的鎖*。

TCC相比較於2PC來說性能會好不少，可是由於同時須要改造try、confirm、canel3個接口，開發成本高。

注意 還有一點須要注意的是Confirm和Cancel操做可能被重複調用，故要求Confirm和Cancel兩個接口必須是冪等。

參考

分佈式事務（一）原理概覽

分佈式事務之說說TCC事務

分佈式事務：深刻理解什麼是2PC、3PC及TCC協議

柔性事務 ：TCC兩階段補償型

只要本身變優秀了，其餘的事情纔會跟着好起來（上將6）