轉載自??什么是 TCC分布式事務

近兩年微服務變得越來越火熱，各種框架與組件的出現，更是為微服務的開發提供了便利。

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

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

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

什么是柔性事務TCC？

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

?

整個柔性事務有多種實現的思想，例如：

?

具體使用

之前的項目開發中，我們也有類似的場景需要保證兩個微服務間的一致性，根據具體的場景需要，用到了TCC事務。當時是通過部門的一個基礎組件，是通過異步補償的形式來保證。

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

基本實現原理

這些TCC的框架，基本都是通過「注解」的形式，在注解中聲明Confirm方法與Cancel方法，再通過AOP對帶點該注解的方法統一進行攔截，之后根據結果分別再執行 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)?{

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

?

補充說明:

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。