分散式事務(2)---TCC理論

雨點的名字發表於2019-07-11

分散式事務(2)---TCC理論

上篇講過有關2PC和3PC理論知識,部落格:分散式事務(1)---2PC和3PC理論

我的理解:2PC、3PC還有TCC都蠻相似的。3PC大致是把2PC的第一階段拆分成了兩個階段,而TCC我感覺是把2PC的第二階段拆分成了兩個階段

一、概念

1、概念

TCC又稱補償事務。其核心思想是:"針對每個操作都要註冊一個與其對應的確認和補償(撤銷操作)"。它分為三個操作:

1、Try階段:主要是對業務系統做檢測及資源預留。
2、Confirm階段:確認執行業務操作。
3、Cancel階段:取消執行業務操作。

TCC對應 Try、Confirm、Cancel 三種操作可以理解成關係型資料庫事務的三種操作:DML、Commit、Rollback

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

TryTry操作是先把多個應用中的業務資源預留和鎖定住,為後續的確認打下基礎,類似的,DML操作要鎖定資料庫記錄行,持有資料庫資源。

ConfirmConfirm操作是在Try操作中涉及的所有應用均成功之後進行確認,使用預留的業務資源,和Commit類似;

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

TCC的具體原理圖如(盜圖):
分散式事務(2)---TCC理論

從圖中我們可以明顯看到Confirm和Cancel操作是一對反向業務操作 即要try返回成功執行Confirm,要麼try返回失敗執行Cancel操作

分散式事務協調者:分散式事務協調者管理控制整個業務活動,包括記錄維護TCC全域性事務的事務狀態和每個從業務服務的子事務狀態,並在業務活動提交時確認所有的TCC型

操作的confirm操作,在業務活動取消時呼叫所有TCC型操作的cancel操作。

2、舉例

例子: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被凍結的金額解凍掉。

3、TCC和2PC比較

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

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

如果有其他人需要更新這兩條記錄,那麼就必須等待鎖釋放。

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

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

出現其他併發程式扣減了這兩個帳戶的餘額而導致在後續的真正轉帳操作過程中,帳戶A和B的可用餘額不夠的情況,同時保證不會一直鎖住整個資源。(核心點應該就在這)

TCC中的兩階段提交併沒有對開發者完全遮蔽,也就是說從程式碼層面,開發者是可以感受到兩階段提交的存在。

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

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

由於是多個獨立的本地事務,因此不會對資源一直加鎖。

總的來講

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

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

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

TCC相比較於2PC來講效能會好很多,但是因為同時需要改造try、confirm、canel3個介面,開發成本高。

注意 還有一點需要注意的是Confirm和Cancel操作可能被重複呼叫,故要求Confirm和Cancel兩個介面必須是冪等


參考

分散式事務(一)原理概覽

分散式事務之說說TCC事務

分散式事務:深入理解什麼是2PC、3PC及TCC協議

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



只要自己變優秀了,其他的事情才會跟著好起來(上將6)

相關文章