來源：https://www.bytesoft.org/ 

一個(gè)TCC事務(wù)框架需要解決的當(dāng)然是分布式事務(wù)的管理。關(guān)于TCC事務(wù)機(jī)制的介紹，可以參考TCC事務(wù)機(jī)制簡介。
TCC事務(wù)模型雖然說起來簡單，然而要基于TCC實(shí)現(xiàn)一個(gè)通用的分布式事務(wù)框架，卻比它看上去要復(fù)雜的多，不只是簡單的調(diào)用一下Confirm/Cancel業(yè)務(wù)就可以了的。

本文將以Spring容器為例，試圖分析一下，實(shí)現(xiàn)一個(gè)通用的TCC分布式事務(wù)框架需要注意的一些問題。

一、TCC全局事務(wù)必須基于RM本地事務(wù)來實(shí)現(xiàn)

TCC服務(wù)是由Try/Confirm/Cancel業(yè)務(wù)構(gòu)成的，其Try/Confirm/Cancel業(yè)務(wù)在執(zhí)行時(shí)，會(huì)訪問資源管理器（Resource Manager，下文簡稱RM）來存取數(shù)據(jù)。

這些存取操作，必須要參與RM本地事務(wù)，以使其更改的數(shù)據(jù)要么都commit，要么都rollback。

假設(shè)圖中的服務(wù)B沒有基于RM本地事務(wù)（以RDBS為例，可通過設(shè)置auto-commit為true來模擬），那么一旦[B:Try]操作中途執(zhí)行失敗，TCC事務(wù)框架后續(xù)決定回滾全局事務(wù)時(shí)，該[B:Cancel]則需要判斷[B:Try]中哪些操作已經(jīng)寫到DB、哪些操作還沒有寫到DB.

假設(shè)[B:Try]業(yè)務(wù)有5個(gè)寫庫操作，[B:Cancel]業(yè)務(wù)則需要逐個(gè)判斷這5個(gè)操作是否生效，并將生效的操作執(zhí)行反向操作。
不幸的是，由于[B:Cancel]業(yè)務(wù)也有n（0<=n<=5）個(gè)反向的寫庫操作，此時(shí)一旦[B:Cancel]也中途出錯(cuò)，則后續(xù)的[B:Cancel]執(zhí)行任務(wù)更加繁重。

因?yàn)橄啾鹊谝淮蝃B:Cancel]操作，后續(xù)的[B:Cancel]操作還需要判斷先前的[B:Cancel]操作的n（0<=n<=5）個(gè)寫庫中哪幾個(gè)已經(jīng)執(zhí)行、哪幾個(gè)還沒有執(zhí)行.

這就涉及到了冪等性問題，而對冪等性的保障，又很可能還需要涉及額外的寫庫操作，該寫庫操作又會(huì)因?yàn)闆]有RM本地事務(wù)的支持而存在類似問題。。。

可想而知，如果不基于RM本地事務(wù)，TCC事務(wù)框架是無法有效的管理TCC全局事務(wù)的。

反之，基于RM本地事務(wù)的TCC事務(wù)，這種情況則會(huì)很容易處理。

[B:Try]操作中途執(zhí)行失敗，TCC事務(wù)框架將其參與RM本地事務(wù)直接rollback即可。后續(xù)TCC事務(wù)框架決定回滾全局事務(wù)時(shí)，在知道“[B:Try]操作涉及的RM本地事務(wù)已經(jīng)rollback”的情況下，根本無需執(zhí)行[B:Cancel]操作。

換句話說，基于RM本地事務(wù)實(shí)現(xiàn)TCC事務(wù)框架時(shí)，一個(gè)TCC型服務(wù)的cancel業(yè)務(wù)要么執(zhí)行，要么不執(zhí)行，不需要考慮部分執(zhí)行的情況。

二、TCC事務(wù)框架應(yīng)該接管Spring容器的TransactionManager

基于RM本地事務(wù)的TCC事務(wù)框架，可以將各Try/Confirm/Cancel業(yè)務(wù)看成一個(gè)原子服務(wù)：一個(gè)RM本地事務(wù)提交，參與該RM本地事務(wù)的所有Try/Confirm/Cancel業(yè)務(wù)操作都生效；反之，則都不生效。

掌握每個(gè)RM本地事務(wù)的狀態(tài)以及它們與Try/Confirm/Cancel業(yè)務(wù)方法之間的對應(yīng)關(guān)系，以此為基礎(chǔ)，TCC事務(wù)框架才能有效的構(gòu)建TCC全局事務(wù)。

TCC服務(wù)的Try/Confirm/Cancel業(yè)務(wù)方法在RM上的數(shù)據(jù)存取操作，其RM本地事務(wù)是由Spring容器的PlatformTransactionManager來commit/rollback的，TCC事務(wù)框架想要了解RM本地事務(wù)的狀態(tài)，只能通過接管Spring的事務(wù)管理器功能。

2.1. 為什么TCC事務(wù)框架需要掌握RM本地事務(wù)的狀態(tài)？
首先，根據(jù)TCC機(jī)制的定義，TCC事務(wù)是通過執(zhí)行Cancel業(yè)務(wù)來達(dá)到回滾效果的。仔細(xì)分析一下，這里暗含一個(gè)事實(shí)：只有生效的Try業(yè)務(wù)操作才需要執(zhí)行對應(yīng)的Cancel業(yè)務(wù)操作。

換句話說，只有Try業(yè)務(wù)操作所參與的RM本地事務(wù)被commit了，后續(xù)TCC全局事務(wù)回滾時(shí)才需要執(zhí)行其對應(yīng)的Cancel業(yè)務(wù)操作

否則，如果Try業(yè)務(wù)操作所參與的RM本地事務(wù)被rollback了，后續(xù)TCC全局事務(wù)回滾時(shí)就不能執(zhí)行其Cancel業(yè)務(wù)，此時(shí)若盲目執(zhí)行Cancel業(yè)務(wù)反而會(huì)導(dǎo)致數(shù)據(jù)不一致。

其次，Confirm/Cancel業(yè)務(wù)操作必須保證生效。Confirm/Cancel業(yè)務(wù)操作也會(huì)涉及RM數(shù)據(jù)存取操作，其參與的RM本地事務(wù)也必須被commit。

TCC事務(wù)框架需要在確切的知道所有Confirm/Cancel業(yè)務(wù)操作參與的RM本地事務(wù)都被成功commit后，才能將標(biāo)記該TCC全局事務(wù)為完成。

如果TCC事務(wù)框架誤判了Confirm/Cancel業(yè)務(wù)參與RM本地事務(wù)的狀態(tài)，就會(huì)造成全局事務(wù)不一致。

最后，未完成的TCC全局，TCC事務(wù)框架必須重新嘗試提交/回滾操作。重試時(shí)會(huì)再次調(diào)用各TCC服務(wù)的Confirm/Cancel業(yè)務(wù)操作。

如果某個(gè)服務(wù)的Confirm/Cancel業(yè)務(wù)之前已經(jīng)生效（其參與的RM本地事務(wù)已經(jīng)提交），重試時(shí)就不應(yīng)該再次被調(diào)用。否則，其Confirm/Cancel業(yè)務(wù)被多次調(diào)用，就會(huì)有“服務(wù)冪等性”的問題。

2.2. 攔截TCC服務(wù)的Try/Confirm/Cancel業(yè)務(wù)方法的執(zhí)行，根據(jù)其異常信息可否知道其RM本地事務(wù)是否commit/rollback了呢？

基本上很難做到，為什么這么說？
第一，事務(wù)是可以在多個(gè)（本地/遠(yuǎn)程）服務(wù)之間互相傳播其事務(wù)上下文的，一個(gè)業(yè)務(wù)方法（Try/Confirm/Cancel）執(zhí)行完畢并不一定會(huì)觸發(fā)當(dāng)前事務(wù)的commit/rollback操作。

比如，被傳播事務(wù)上下文的業(yè)務(wù)方法，在它開始執(zhí)行時(shí)，容器并不會(huì)為其創(chuàng)建新的事務(wù)，而是它的調(diào)用方參與的事務(wù)，使得二者操作在同一個(gè)事務(wù)中；同樣，在它執(zhí)行完畢時(shí)，容器也不會(huì)提交/回滾它參與的事務(wù)的。

因此，這類業(yè)務(wù)方法上的異常情況并不能反映他們是否生效。不接管Spring的TransactionManager，就無法了解事務(wù)于何時(shí)被創(chuàng)建，也無法了解它于何時(shí)被提交/回滾。
第二、一個(gè)業(yè)務(wù)方法可能會(huì)包含多個(gè)RM本地事務(wù)的情況。

比如：A(REQUIRED)->B(REQUIRES_NEW)->C(REQUIRED)，這種情況下，A服務(wù)所參與的RM本地事務(wù)被提交時(shí)，B服務(wù)和C服務(wù)參與的RM本地事務(wù)則可能會(huì)被回滾。
第三、并不是拋出了異常的業(yè)務(wù)方法，其參與的事務(wù)就回滾了。

Spring容器的聲明式事務(wù)定義了兩類異常，其事務(wù)完成方向都不一樣：系統(tǒng)異常（一般為Unchecked異常，默認(rèn)事務(wù)完成方向是rollback）、應(yīng)用異常（一般為Checked異常，默認(rèn)事務(wù)完成方向是commit）。

二者的事務(wù)完成方向又可以通過@Transactional配置顯式的指定，如rollbackFor/noRollbackFor等。
第四、Spring容器還支持使用setRollbackOnly的方式顯式的控制事務(wù)完成方向；
最后，自行攔截業(yè)務(wù)方法的攔截器和Spring的事務(wù)處理的攔截器還會(huì)存在執(zhí)行先后、攔截范圍不同等問題。

例如，如果自行攔截器執(zhí)行在前，就會(huì)出現(xiàn)業(yè)務(wù)方法雖然已經(jīng)執(zhí)行完畢但此時(shí)其參與的RM本地事務(wù)還沒有commit/rollback。

TCC事務(wù)框架的定位應(yīng)該是一個(gè)TransactionManager，其職責(zé)是負(fù)責(zé)commit/rollback事務(wù)。

而一個(gè)事務(wù)應(yīng)該commit、還是rollback，則應(yīng)該是由Spring容器來決定的：

Spring決定提交事務(wù)時(shí)，會(huì)調(diào)用TransactionManager來完成commit操作；Spring決定回滾事務(wù)時(shí)，會(huì)調(diào)用TransactionManager來完成rollback操作。

接管Spring容器的TransactionManager，TCC事務(wù)框架可以明確的得到Spring的事務(wù)性指令，并管理Spring容器中各服務(wù)的RM本地事務(wù)。

否則，如果通過自行攔截的機(jī)制，則使得業(yè)務(wù)系統(tǒng)存在TCC事務(wù)處理、RM本地事務(wù)處理兩套事務(wù)處理邏輯，二者互不通信，各行其是。

這種情況下要協(xié)調(diào)TCC全局事務(wù)，基本上可以說是緣木求魚，本地事務(wù)尚且無法管理，更何談管理分布式事務(wù)？

三、TCC事務(wù)框架應(yīng)該具備故障恢復(fù)機(jī)制

一個(gè)TCC事務(wù)框架，若是沒有故障恢復(fù)的保障，是不成其為分布式事務(wù)框架的。

分布式事務(wù)管理框架的職責(zé)，不是做出全局事務(wù)提交/回滾的指令，而是管理全局事務(wù)提交/回滾的過程。

它需要能夠協(xié)調(diào)多個(gè)RM資源、多個(gè)節(jié)點(diǎn)的分支事務(wù)，保證它們按全局事務(wù)的完成方向各自完成自己的分支事務(wù)。

這一點(diǎn)，是不容易做到的。因?yàn)?，?shí)際應(yīng)用中，會(huì)有各種故障出現(xiàn)，很多都會(huì)造成事務(wù)的中斷，從而使得統(tǒng)一提交/回滾全局事務(wù)的目標(biāo)不能達(dá)到，甚至出現(xiàn)”一部分分支事務(wù)已經(jīng)提交，而另一部分分支事務(wù)則已回滾”的情況。

比較常見的故障，比如：業(yè)務(wù)系統(tǒng)服務(wù)器宕機(jī)、重啟；數(shù)據(jù)庫服務(wù)器宕機(jī)、重啟；網(wǎng)絡(luò)故障；斷電等。這些故障可能單獨(dú)發(fā)生，也可能會(huì)同時(shí)發(fā)生。

作為分布式事務(wù)框架，應(yīng)該具備相應(yīng)的故障恢復(fù)機(jī)制，無視這些故障的影響是不負(fù)責(zé)任的做法。

一個(gè)完整的分布式事務(wù)框架，應(yīng)該保障即使在最嚴(yán)苛的條件下也能保證全局事務(wù)的一致性，而不是只能在最理想的環(huán)境下才能提供這種保障。退一步說，如果能有所謂“理想的環(huán)境”，那也無需使用分布式事務(wù)了。

TCC事務(wù)框架要支持故障恢復(fù)，就必須記錄相應(yīng)的事務(wù)日志。事務(wù)日志是故障恢復(fù)的基礎(chǔ)和前提，它記錄了事務(wù)的各項(xiàng)數(shù)據(jù)。

TCC事務(wù)框架做故障恢復(fù)時(shí)，可以根據(jù)事務(wù)日志的數(shù)據(jù)將中斷的事務(wù)恢復(fù)至正確的狀態(tài)，并在此基礎(chǔ)上繼續(xù)執(zhí)行先前未完成的提交/回滾操作。

四、TCC事務(wù)框架應(yīng)該提供Confirm/Cancel服務(wù)的冪等性保障

一般認(rèn)為，服務(wù)的冪等性，是指針對同一個(gè)服務(wù)的多次(n>1)請求和對它的單次(n=1)請求，二者具有相同的副作用。

在TCC事務(wù)模型中，Confirm/Cancel業(yè)務(wù)可能會(huì)被重復(fù)調(diào)用，其原因很多。

比如，全局事務(wù)在提交/回滾時(shí)會(huì)調(diào)用各TCC服務(wù)的Confirm/Cancel業(yè)務(wù)邏輯。執(zhí)行這些Confirm/Cancel業(yè)務(wù)時(shí)，可能會(huì)出現(xiàn)如網(wǎng)絡(luò)中斷的故障而使得全局事務(wù)不能完成。

因此，故障恢復(fù)機(jī)制后續(xù)仍然會(huì)重新提交/回滾這些未完成的全局事務(wù)，這樣就會(huì)再次調(diào)用參與該全局事務(wù)的各TCC服務(wù)的Confirm/Cancel業(yè)務(wù)邏輯。

既然Confirm/Cancel業(yè)務(wù)可能會(huì)被多次調(diào)用，就需要保障其冪等性。
那么，應(yīng)該由TCC事務(wù)框架來提供冪等性保障？還是應(yīng)該由業(yè)務(wù)系統(tǒng)自行來保障冪等性呢？
個(gè)人認(rèn)為，應(yīng)該是由TCC事務(wù)框架來提供冪等性保障。如果僅僅只是極個(gè)別服務(wù)存在這個(gè)問題的話，那么由業(yè)務(wù)系統(tǒng)來負(fù)責(zé)也是可以的；

然而，這是一類公共問題，毫無疑問，所有TCC服務(wù)的Confirm/Cancel業(yè)務(wù)存在冪等性問題。TCC服務(wù)的公共問題應(yīng)該由TCC事務(wù)框架來解決；

而且，考慮一下由業(yè)務(wù)系統(tǒng)來負(fù)責(zé)冪等性需要考慮的問題，就會(huì)發(fā)現(xiàn)，這無疑增大了業(yè)務(wù)系統(tǒng)的復(fù)雜度。

五、TCC事務(wù)框架不能盲目的依賴Cancel業(yè)務(wù)來回滾事務(wù)

前文以及提到過，TCC事務(wù)通過Cancel業(yè)務(wù)來對Try業(yè)務(wù)進(jìn)行回撤的機(jī)制暗含了一個(gè)事實(shí)：Try操作已經(jīng)生效。

也就是說，只有Try操作所參與的RM本地事務(wù)已經(jīng)提交的情況下，才需要執(zhí)行其Cancel操作進(jìn)行回撤。沒有執(zhí)行、或者執(zhí)行了但是其RM本地事務(wù)被rollback的Try業(yè)務(wù)，是一定不能執(zhí)行其Cancel業(yè)務(wù)進(jìn)行回撤的。

因此，TCC事務(wù)框架在全局事務(wù)回滾時(shí)，應(yīng)該根據(jù)TCC服務(wù)的Try業(yè)務(wù)的執(zhí)行情況選擇合適的處理機(jī)制。而不能盲目的執(zhí)行Cancel業(yè)務(wù)，否則就會(huì)導(dǎo)致數(shù)據(jù)不一致。

一個(gè)TCC服務(wù)的Try操作是否生效，這是TCC事務(wù)框架應(yīng)該知道的，因?yàn)槠銽ry業(yè)務(wù)所參與的RM事務(wù)也是由TCC事務(wù)框架所commit/rollbac的（前提是TCC事務(wù)框架接管了Spring的事務(wù)管理器）。

所以，TCC事務(wù)回滾時(shí)，TCC事務(wù)框架可考慮如下處理策略：

1. 如果TCC事務(wù)框架發(fā)現(xiàn)某個(gè)服務(wù)的Try操作的本地事務(wù)尚未提交，應(yīng)該直接將其回滾，而后就不必再執(zhí)行該服務(wù)的cancel業(yè)務(wù)；

2. 如果TCC事務(wù)框架發(fā)現(xiàn)某個(gè)服務(wù)的Try操作的本地事務(wù)已經(jīng)回滾，則不必再執(zhí)行該服務(wù)的cancel業(yè)務(wù)；

3. 如果TCC事務(wù)框架發(fā)現(xiàn)某個(gè)服務(wù)的Try操作尚未被執(zhí)行過，那么，也不必再執(zhí)行該服務(wù)的cancel業(yè)務(wù)。

總之，TCC事務(wù)框架應(yīng)該保障：

1. 已生效的Try操作應(yīng)該被其Cancel操作所回撤；

2. 尚未生效的Try操作，則不應(yīng)該執(zhí)行其Cancel操作。這一點(diǎn)，不是冪等性所能解決的問題。如上文所述，冪等性是指服務(wù)被執(zhí)行一次和被執(zhí)行n(n>0)次所產(chǎn)生的影響相同。但是，未被執(zhí)行和被執(zhí)行過，二者效果肯定是不一樣的，這不屬于冪等性的范疇。

六、Cancel業(yè)務(wù)與Try業(yè)務(wù)并行，甚至先于Try操作完成

這應(yīng)該算TCC事務(wù)機(jī)制特有的一個(gè)不可思議的陷阱。

一般來說，一個(gè)特定的TCC服務(wù)，其Try操作的執(zhí)行，是應(yīng)該在其Confirm/Cancel操作之前的。

Try操作執(zhí)行完畢之后，Spring容器再根據(jù)Try操作的執(zhí)行情況，指示TCC事務(wù)框架提交/回滾全局事務(wù)。然后，TCC事務(wù)框架再去逐個(gè)調(diào)用各TCC服務(wù)的Confirm/Cancel操作。

然而，超時(shí)、網(wǎng)絡(luò)故障、服務(wù)器的重啟等故障的存在，使得這個(gè)順序會(huì)被打亂。比如：

上圖中，假設(shè)[B:Try]操作執(zhí)行過程中，網(wǎng)絡(luò)閃斷，[A:Try]會(huì)收到一個(gè)RPC遠(yuǎn)程調(diào)用異常。

A不處理該異常，導(dǎo)致全局事務(wù)決定回滾，TCC事務(wù)框架就會(huì)去調(diào)用[B:Cancel]，而此刻A、B之間網(wǎng)絡(luò)剛好已經(jīng)恢復(fù)。如果[B:Try]操作耗時(shí)較長（網(wǎng)絡(luò)阻塞/數(shù)據(jù)庫操作阻塞），就會(huì)出現(xiàn)[B:Try]和[B:Cancel]二者并行處理的現(xiàn)象，甚至[B:Cancel]先完成的現(xiàn)象。

這種情況下，由于[B:Cancel]執(zhí)行時(shí)，[B:Try]尚未生效（其RM本地事務(wù)尚未提交），因此，[B:Cancel]是不能執(zhí)行的，至少是不能生效（執(zhí)行了其RM本地事務(wù)也要rollback）的。

然而，當(dāng)[B:Cancel]處理完畢（跳過執(zhí)行、或者執(zhí)行后rollback其RM本地事務(wù)）后，[B:Try]操作完成又生效了（其RM本地事務(wù)成功提交），這就會(huì)使得[B:Cancel]雖然提供了，但卻沒有起到回撤[B:Try]的作用，導(dǎo)致數(shù)據(jù)的不一致。

所以，TCC框架在這種情況下，需要：

1. 將[B:Try]的本地事務(wù)標(biāo)注為rollbackOnly，阻止其后續(xù)生效；

2. 禁止其再次將事務(wù)上下文傳遞給其他遠(yuǎn)程分支，否則該問題將在其他分支上出現(xiàn)；

3. 相應(yīng)地，[B:Cancel]也不必執(zhí)行，至少不能生效。

當(dāng)然，TCC事務(wù)框架也可以簡單的選擇阻塞[B:Cancel]的處理，待[B:Try]執(zhí)行完畢后，再根據(jù)它的執(zhí)行情況判斷是否需要執(zhí)行[B:Cancel]。

不過，這種處理方式因?yàn)樾枰却?，所以，處理效率上?huì)有所不及。

同樣的情況也會(huì)出現(xiàn)在confirm業(yè)務(wù)上，只不過，發(fā)生在Confirm業(yè)務(wù)上的處理邏輯與發(fā)生在Cancel業(yè)務(wù)上的處理邏輯會(huì)不一樣。

TCC框架必須保證：

1. Confirm業(yè)務(wù)在Try業(yè)務(wù)之后執(zhí)行，若發(fā)現(xiàn)并行，則只能阻塞相應(yīng)的Confirm業(yè)務(wù)操作；

2. 在進(jìn)入Confirm執(zhí)行階段之后，也不可以再提交同一全局事務(wù)內(nèi)的新的Try操作的RM本地事務(wù)。

七、TCC服務(wù)復(fù)用性是不是相對較差？

TCC事務(wù)機(jī)制的定義，決定了一個(gè)服務(wù)需要提供三個(gè)業(yè)務(wù)實(shí)現(xiàn)：Try業(yè)務(wù)、Confirm業(yè)務(wù)、Cancel業(yè)務(wù)。

可能會(huì)有人因此認(rèn)為TCC服務(wù)的復(fù)用性較差。怎么說呢，要是將 Try/Confirm/Cancel業(yè)務(wù)邏輯單獨(dú)拿出來復(fù)用，其復(fù)用性當(dāng)然是不好的。

Try/Confirm/Cancel 邏輯作為TCC型服務(wù)中的一部分，是不能單獨(dú)作為一個(gè)組件來復(fù)用的。Try、Confirm、Cancel業(yè)務(wù)共同才構(gòu)成一個(gè)組件，如果要復(fù)用，應(yīng)該是復(fù)用整個(gè)TCC服務(wù)組件，而不是單獨(dú)的Try/Confirm/Cancel業(yè)務(wù)。

八、TCC服務(wù)是否需要對外暴露三個(gè)服務(wù)接口？

不需要。TCC服務(wù)與普通的服務(wù)一樣，只需要暴露一個(gè)接口，也就是它的Try業(yè)務(wù)。

Confirm/Cancel業(yè)務(wù)邏輯，只是因?yàn)槿质聞?wù)提交/回滾的需要才提供的，因此Confirm/Cancel業(yè)務(wù)只需要被TCC事務(wù)框架發(fā)現(xiàn)即可，不需要被調(diào)用它的其他業(yè)務(wù)服務(wù)所感知。

換句話說，業(yè)務(wù)系統(tǒng)的其他服務(wù)在需要調(diào)用TCC服務(wù)時(shí)，根本不需要知道它是否為TCC型服務(wù)。

因?yàn)?，TCC服務(wù)能被其他業(yè)務(wù)服務(wù)調(diào)用的也僅僅是其Try業(yè)務(wù)，Confirm/Cancel業(yè)務(wù)是不能被其他業(yè)務(wù)服務(wù)直接調(diào)用的。

九、TCC服務(wù)A的Confirm/Cancel業(yè)務(wù)中能否調(diào)用它依賴的TCC服務(wù)B的Confirm/Cancel業(yè)務(wù)？

最好不要這樣做。

首先，沒有必要。TCC服務(wù)A依賴TCC服務(wù)B，那么[A:Try]已經(jīng)將事務(wù)上下文傳播給[B:Try]了，后續(xù)由TCC事務(wù)框架來調(diào)用各自的Confirm/Cancel業(yè)務(wù)即可；

其次，Confirm/Cancel業(yè)務(wù)如果被允許調(diào)用其他服務(wù)，那么它就有可能再次發(fā)起新的TCC全局事務(wù)。如此遞歸下去，將會(huì)導(dǎo)致全局事務(wù)關(guān)系混亂且不可控。

TCC全局事務(wù)，應(yīng)該盡量在Try操作階段傳播事務(wù)上下文。Confirm/Cancel操作階段僅需要完成各自Try業(yè)務(wù)操作的確認(rèn)操作/補(bǔ)償操作即可，不適合再做遠(yuǎn)程調(diào)用，更不能再對外傳播事務(wù)上下文。

綜上所述，本文傾向于認(rèn)為，實(shí)現(xiàn)一個(gè)通用的TCC分布式事務(wù)管理框架，還是相對比較復(fù)雜的。一般業(yè)務(wù)系統(tǒng)如果需要使用TCC事務(wù)機(jī)制，并不推薦自行設(shè)計(jì)實(shí)現(xiàn)。
這里，給大家推薦一款開源的TCC分布式事務(wù)管理器ByteTCC

https://github.com/liuyangming/ByteTCC

ByteTCC基于Try/Confirm/Cancel機(jī)制實(shí)現(xiàn)，可與Spring容器無縫集成，兼容Spring的聲明式事務(wù)管理。提供對dubbo框架、Spring Cloud的開箱即用的支持，可滿足多數(shù)據(jù)源、跨應(yīng)用、跨服務(wù)器等各種分布式事務(wù)場景的需求。