TCC標(biāo)準(zhǔn)編程模型

異常一：try階段異常

在try階段異常之后，就會(huì)執(zhí)行cancel階段，此時(shí)cancel階段是一定要保證成功的，如果cancel階段沒(méi)有執(zhí)行成功，那么就要進(jìn)行重試

異常二：cancel階段異常

其實(shí)這個(gè)異常的處理方式和異常一是一樣的，失敗了就重試，如果一直重試失敗，那么就要進(jìn)行人工干預(yù)

異常三：confirm提交異常

try階段成功了，那么confirm一定要成功，如果失敗了，那么就要進(jìn)行重試，重試多次還未成功，那么就要進(jìn)行人工干預(yù)

但是這里重試要注意，因?yàn)樵赾onfirm階段有二步數(shù)據(jù)庫(kù)操作，如果扣凍結(jié)張三20元成功了，但是李四加20元失敗了，這時(shí)候重試就要做判斷，看張三扣減20元是否之前已經(jīng)操作成功了，如果操作成功了，就不要再次進(jìn)行扣減凍結(jié)的操作

異常四：本地事務(wù)與TCC事務(wù)沖突

在try階段我們添加了一個(gè)本地事務(wù)，如果這時(shí)候try階段異常，那么本地事務(wù)就會(huì)回滾，所以這時(shí)候凍結(jié)張三20元的操作就會(huì)回滾，也就不會(huì)被凍結(jié)。那么這時(shí)候try階段異常了，就會(huì)執(zhí)行cancel階段進(jìn)行回滾

在cancel階段，我們會(huì)還張三凍結(jié)的20元，這時(shí)候如果cancel執(zhí)行成功，那么張三的金額就會(huì)多出20元，就會(huì)造成數(shù)據(jù)的不一致，所以一般不要加本地事務(wù)

@Transaction(rollback=Exception.class)
@Hmily(comfirmMethod="confirmMethod",cancelMethod="cancelMethod")
public void try() {
  //查詢(xún)張三余額信息  
  Account account = accountMapper.selectByUserId(1);
  //凍結(jié)張三20元
  account.setDJAccount(20);
  accountMapper.updateById(account);
}

異常五：空回滾

為什么會(huì)有空回滾的異常呢？ 比如我們?cè)趫?zhí)行try階段的時(shí)候，由于超時(shí)了，導(dǎo)致TCC就去執(zhí)行cancel階段了，但是這時(shí)候try階段還沒(méi)有執(zhí)行，也就是try階段還沒(méi)有凍結(jié)張三20元，這時(shí)候就造成了空回滾。

這時(shí)候我們需要引入其它手段，比如增加一張日志表，在回滾的時(shí)候，判斷一下這是事務(wù)有沒(méi)有執(zhí)行try階段，也就是這個(gè)事務(wù)有沒(méi)有執(zhí)行過(guò)try階段，如果沒(méi)有就不要執(zhí)行cancel階段的操作了。

異常六：第二階段重復(fù)提交

第二階段包括confirm，cancel，為什么會(huì)有重復(fù)提交呢？ 因?yàn)槲覀儾荒鼙ＷCconfirm階段或者cancel階段一定能成功，如果不成功那么我們就要進(jìn)行重試，

舉個(gè)例子，在confirm階段有二步數(shù)據(jù)庫(kù)操作，假設(shè)扣減張三凍結(jié)20元成功，但是李四加20元失敗了，這時(shí)候我們就要進(jìn)行重試，但是重試的時(shí)候我們扣減張三凍結(jié)的20元已經(jīng)操作成功了，所以不需要再次扣減了，所以我們要做好類(lèi)似去重的操作，之前操作成功的就不要再次進(jìn)行操作了

異常七：防懸掛

cancel階段比try階段先執(zhí)行，由于網(wǎng)絡(luò)原因?qū)е聇ry階段超時(shí)，這時(shí)候就會(huì)執(zhí)行cancel階段操作，等cancel階段執(zhí)行完了，這時(shí)候try才執(zhí)行，雖然事務(wù)失敗了，但是這個(gè)事務(wù)已經(jīng)結(jié)束了，所以這時(shí)候的try方法一定不能執(zhí)行

以上就是TCC分布式事務(wù)七種異常情況小結(jié)的詳細(xì)內(nèi)容，更多關(guān)于TCC分布式事務(wù)異常的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論