基于TCC如何實(shí)現(xiàn)一個(gè)通用的分布式事務(wù)框架

這篇文章給大家介紹基于TCC如何實(shí)現(xiàn)一個(gè)通用的分布式事務(wù)框架，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

一個(gè)TCC事務(wù)框架需要解決的當(dāng)然是分布式事務(wù)的管理。

TCC事務(wù)模型雖然說起來簡(jiǎn)單，然而要基于TCC實(shí)現(xiàn)一個(gè)通用的分布式事務(wù)框架，卻比它看上去要復(fù)雜的多，不只是簡(jiǎn)單的調(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，下文簡(jiǎn)稱RM)來存取數(shù)據(jù)。

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

這一點(diǎn)不難理解，考慮一下如下場(chǎng)景：

假設(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è)寫庫(kù)操作，[B:Cancel]業(yè)務(wù)則需要逐個(gè)判斷這5個(gè)操作是否生效，并將生效的操作執(zhí)行反向操作。

不幸的是，由于[B:Cancel]業(yè)務(wù)也有n(0<=n<=5)個(gè)反向的寫庫(kù)操作，此時(shí)一旦[B:Cancel]也中途出錯(cuò)，則后續(xù)的[B:Cancel]執(zhí)行任務(wù)更加繁重。

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

這就涉及到了冪等性問題，而對(duì)冪等性的保障，又很可能還需要涉及額外的寫庫(kù)操作，該寫庫(kù)操作又會(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ù)方法之間的對(duì)應(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í)行對(duì)應(yīng)的Cancel業(yè)務(wù)操作。

換句話說，只有Try業(yè)務(wù)操作所參與的RM本地事務(wù)被commit了，后續(xù)TCC全局事務(wù)回滾時(shí)才需要執(zhí)行其對(duì)應(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ù)庫(kù)服務(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í)行先前未完成的提交/回滾操作。關(guān)注微信公眾號(hào)：Java技術(shù)棧，在后臺(tái)回復(fù)：架構(gòu)，可以獲取我整理的  N 篇架構(gòu)教程，都是干貨。

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

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

在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ù)來對(duì)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ù)管理器)。推薦：分布式事務(wù)不理解?一次給你講清楚。

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

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

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

3. 尚未生效的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í)較長(zhǎng)(網(wǎng)絡(luò)阻塞/數(shù)據(jù)庫(kù)操作阻塞)，就會(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. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

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

當(dāng)然，TCC事務(wù)框架也可以簡(jiǎn)單的選擇阻塞[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. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

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

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ù)是否需要對(duì)外暴露三個(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)用，更不能再對(duì)外傳播事務(wù)上下文。

關(guān)于基于TCC如何實(shí)現(xiàn)一個(gè)通用的分布式事務(wù)框架就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。