轉(zhuǎn)載自??什么是 TCC分布式事務(wù)

近兩年微服務(wù)變得越來越火熱，各種框架與組件的出現(xiàn)，更是為微服務(wù)的開發(fā)提供了便利。

我們都知道，每個微服務(wù)都是一個對應(yīng)的小服務(wù)，多個服務(wù)之間可以方便的進行功能的組合，來形成功能更強大的服務(wù)。服務(wù)間數(shù)據(jù)與部署都是獨立的，這樣故障也可以做到相互隔離。但是這也帶來了分布式應(yīng)用都會面對的問題：

如何保證多個服務(wù)間的事務(wù)？怎樣才能使操作的原子性、一致性等得到保證？

對于傳統(tǒng)的應(yīng)用開發(fā)與部署，可以通過數(shù)據(jù)的事務(wù)來保證所謂的ACID,而微服務(wù)的場景下，數(shù)據(jù)庫就力不從心了。
這個時候，2PC、3PC輪番登場，來解決這類的問題。但有些場景下，我們根據(jù)自己的真實需要，并不需要純的2PC，比如你只關(guān)心數(shù)據(jù)的原子性與最終一致性，那2PC階段的阻塞是你不能忍受的，那就有聰明的人想到了一種新的辦法。就是我們今天要說的柔性事務(wù)TCC。

什么是柔性事務(wù)TCC？

我們今天說的柔性事務(wù)，「柔」主要是相對于「傳統(tǒng)」ACID的剛而言，柔性事務(wù)只需要遵循BASE原則。而TCC是柔性事務(wù)的一種實現(xiàn)。TCC是三個首字母，Try-Confirm-Cancel，具體描述是將整個操作分為上面這三步。兩個微服務(wù)間同時進行Try，在Try的階段會進行數(shù)據(jù)的校驗，檢查，資源的預(yù)創(chuàng)建，如果都成功就會分別進行Confirm，如果兩者都成功則整個TCC事務(wù)完成。如果Confirm時有一個服務(wù)有問題，則會轉(zhuǎn)向Cancel，相當于進行Confirm的逆向操作。

?

整個柔性事務(wù)有多種實現(xiàn)的思想，例如：

?

具體使用

之前的項目開發(fā)中，我們也有類似的場景需要保證兩個微服務(wù)間的一致性，根據(jù)具體的場景需要，用到了TCC事務(wù)。當時是通過部門的一個基礎(chǔ)組件，是通過異步補償?shù)男问絹肀ＷC。

目前也有一些開源的TCC實現(xiàn)，可以直接在GitHub上獲取到，例如下面這個https://github.com/changmingxie/tcc-transaction

基本實現(xiàn)原理

這些TCC的框架，基本都是通過「注解」的形式，在注解中聲明Confirm方法與Cancel方法，再通過AOP對帶點該注解的方法統(tǒng)一進行攔截，之后根據(jù)結(jié)果分別再執(zhí)行 Confirm 或者 Cancel。

代碼類似這個樣子：

@Compensable(confirmMethod?=?"confirmRecord",?cancelMethod?=?"cancelRecord",?transactionContextEditor?=?MethodTransactionContextEditor.class) public?String?record(TransactionContext?transactionContext,?CapitalTradeOrderDto?tradeOrderDto)?{

confirm方法

public?void?confirmRecord(TransactionContext?transactionContext,?CapitalTradeOrderDto?tradeOrderDto)?{

cancel方法：

public?void?cancelRecord(TransactionContext?transactionContext,?RedPacketTradeOrderDto?tradeOrderDto)?{

基于類似的框架，可以比較方便的滿足我們的業(yè)務(wù)使用場景。歡迎留言補充你在分布式的場景中是通過什么方式來保證一致性的。

?

補充說明:

文中圖片來源于「支付寶架構(gòu)與技術(shù)」文檔，感興趣的朋友可以自行搜索獲取該文件。

總結(jié)

以上是生活随笔為你收集整理的什么是 TCC分布式事务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。