在分布式事務(wù)解決方案中有Seata AT模式，但是AT模式要求是關(guān)系型數(shù)據(jù)庫(kù)（因?yàn)閡ndolog表需要和業(yè)務(wù)保持原子性），此時(shí)如果事務(wù)中存在非關(guān)系型數(shù)據(jù)庫(kù)（如Redis、ES等），那么AT模式就無(wú)法滿足要求了，如下圖所示：

圖片

此時(shí)我們就需要Seata TCC模式來(lái)幫助我們解決這種場(chǎng)景下的分布式事務(wù)問(wèn)題。

1、認(rèn)識(shí)Seata TCC模式

TCC(Try-Confirm-Cancel)模式是一種補(bǔ)償性事務(wù)模式的解決方案，因?yàn)檠a(bǔ)償?shù)臉I(yè)務(wù)需要使用者自己寫，不像AT模式那樣的無(wú)侵入性的分布式事務(wù)處理方案，如下是TCC模式的執(zhí)行流程圖：

圖片

TCC將一個(gè)完整的業(yè)務(wù)操作分為三個(gè)階段，如下圖整理所示：

圖片

Try階段：嘗試執(zhí)行業(yè)務(wù)操作，預(yù)留必要的業(yè)務(wù)資源，并檢查數(shù)據(jù)的有效性。

Confirm階段：如果Try階段所有參與的操作都成功，則進(jìn)入Confirm階段就會(huì)正式完成業(yè)務(wù)操作，提交事務(wù)，并釋放在Try階段預(yù)留的資源。

Cancel階段：如果Try階段有任何一個(gè)操作失敗，或者由于某種原因需要回滾事務(wù)，則觸發(fā)Cancel階段，撤銷所有已執(zhí)行的Try操作，回滾到事務(wù)開(kāi)始之前的狀態(tài)，并釋放預(yù)留的資源。

2、理解TCC模式

為了方便理解TCC模式，以A（賬戶總額1000元）向B（賬戶總額2000元）轉(zhuǎn)賬100元為例進(jìn)行解析，那么TCC模式下的操作流程如下圖所示：

圖片

Try階段的工作：A賬戶先從總資金中扣除100元，但是這個(gè)100處于凍結(jié)狀態(tài)；B賬戶預(yù)增加100元，這個(gè)100處于不可用狀態(tài)。如下圖所示：

圖片

（a）如果A與B在Try階段都正常的執(zhí)行，接下來(lái)就是執(zhí)行Confirm階段的任務(wù)，A賬戶凍結(jié)100變成0元，這個(gè)100真正的轉(zhuǎn)給B賬戶；B賬戶的總額增加100元，預(yù)增加的金額變成0元，如下圖所示：

圖片

（b）如果A與B在Try階段未正常的執(zhí)行，接下來(lái)A賬戶的凍結(jié)100變成0元，恢復(fù)A賬戶的資金的總額；B賬戶資金的總額不變化，預(yù)增加的金額變成0元，如下圖所示：

圖片

3、Seata TCC事務(wù)模型的三種異常

在TCC事務(wù)模型涉及到的三種異常（空回滾、冪等性、防懸掛）是不可避免的，下面我們來(lái)了解這三種異常發(fā)生的原因以及處理方案。

（1）空回滾

A調(diào)用C的時(shí)候，由于網(wǎng)絡(luò)抖動(dòng)的原因?qū)е翪沒(méi)有請(qǐng)求成功，此時(shí)服務(wù)超時(shí)走兜底機(jī)制返回異常給A，如下圖所示：

圖片

當(dāng)A發(fā)現(xiàn)B服務(wù)異常，TC就會(huì)通知A、B、C執(zhí)行回滾操作，但是C由于Try階段都沒(méi)有執(zhí)行就直接執(zhí)行Cancel階段，最終就可能導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不一致性。

空回滾處理方案：

Cancel執(zhí)行的前提是一定要執(zhí)行過(guò)Try階段，所以增加一個(gè)日志表來(lái)記錄是否執(zhí)行Try階段，如果沒(méi)有執(zhí)行Try階段，那么Cancel階段也不執(zhí)行。

（2）冪等性

TCC中二階段的方法被多次的調(diào)用（二階段會(huì)有定時(shí)器不斷的重試），如下如所示：

圖片

冪等性處理方案：狀態(tài)機(jī)方式

在日志表中執(zhí)行更新操作的時(shí)候（update log set status= 2 where status= 1）通過(guò)獲取影響行數(shù)來(lái)判斷是否執(zhí)行成功，如果影響行數(shù)為0就不繼續(xù)處理；如果影響行數(shù)不為0就繼續(xù)Cancel的業(yè)務(wù)邏輯。

（3）防懸掛

由于網(wǎng)絡(luò)擁堵等原因?qū)е翧調(diào)用C的Try方法的請(qǐng)求發(fā)送成功，但是C與A之間自動(dòng)斷開(kāi)了連接，導(dǎo)致A認(rèn)為C執(zhí)行異常了，此時(shí)TC發(fā)送執(zhí)行回滾操作命令，這就導(dǎo)致Cancel階段比Try先執(zhí)行，如下圖所示：

圖片

當(dāng)C服務(wù)做完Try階段的工作后，此時(shí)資源被預(yù)留出來(lái)了；但是Cancel已經(jīng)執(zhí)行完成了，表示那么整個(gè)事務(wù)就結(jié)束了，進(jìn)而導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不一致性。

防懸掛問(wèn)題的處理方案：日志表

在Cancel執(zhí)行完成之后要保證Try方法不能再執(zhí)行了，此時(shí)在日志表中增加一條Cancel的記錄，等到Try執(zhí)行的時(shí)候，其也要增加一條記錄，但是由于Cancel增加了日志記錄，此時(shí)Try就增加失敗，進(jìn)而阻止Try繼續(xù)執(zhí)行。

總結(jié)：

（1）TCC模式資源鎖定時(shí)間短：相較于傳統(tǒng)的兩階段提交(2PC)，TCC模式可以減少資源鎖定的時(shí)間，因?yàn)橘Y源僅在Try階段被預(yù)留，并在Confirm或Cancel階段迅速釋放。

（2）TCC模式業(yè)務(wù)邏輯靈活：我們可以根據(jù)業(yè)務(wù)需求自定義每個(gè)階段的邏輯，使得TCC模式非常靈活。

（3）TCC模式保證強(qiáng)一致性：它可以確保事務(wù)要么都成功，要么都回滾。

（4）TCC模式實(shí)現(xiàn)復(fù)雜（需要為每個(gè)業(yè)務(wù)操作明確定義Try、Confirm和Cancel三個(gè)階段的邏輯）、增加了協(xié)調(diào)開(kāi)銷、業(yè)務(wù)侵入性（業(yè)務(wù)邏輯與事務(wù)邏輯耦合）。