什麼是 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) {
基於類似的框架，可以比較方便的滿足我們的業務使用場景。 歡迎留言補充你在分散式的場景中是通過什麼方式來保證一致性的。
補充說明:
文中圖片來源於「支付寶架構與技術」文件，感興趣的朋友可以自行搜尋獲取該檔案。
原文釋出時間為：2018-09-7
本文作者：xxx
本文來自雲棲社群合作伙伴“ ofollow,noindex">程式員小灰 ”，瞭解相關資訊可以關注“ 程式設計師小灰 ”。