"TCC是分散式事務實現的一種方式TRYING 階段主要是對業務系統做檢測及資源預留CONFIRMING 階段主要是對業務系統做確認提交，TRYING階段執行成功並開始執行CONFIRMING階段時，預設CONFIRMING階段是不會出錯的。即：只要TRYING成功，CONFIRMING一定成功。CANCELING 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。而冪等性則是指業務方法呼叫一次與呼叫多次的執行返回結果是一樣的。舉個支付專案的例子：支付系統接收到會員的支付請求後，需要扣減會員賬戶餘額、增加會員積分（暫時假設需要同步實現）增加商戶賬戶餘額再假設：會員系統、商戶系統、積分系統是獨立的三個子系統，無法透過傳統的事務方式進行處理。TRYING階段：我們需要做的就是會員資金賬戶的資金預留，即：凍結會員賬戶的金額（訂單金額）CONFIRMING階段：我們需要做的就是會員積分賬戶增加積分餘額，商戶賬戶增加賬戶餘額CANCELING階段：該階段需要執行的就是解凍釋放我們扣減的會員餘額以上所有的操作需要滿足冪等性，冪等性的實現方式可以是：1、透過唯一鍵值做處理，即每次呼叫的時候傳入唯一鍵值，透過唯一鍵值判斷業務是否被操作，如果已被操作，則不再重複操作2、透過狀態機處理，給業務資料設定狀態，透過業務狀態判斷是否需要重複執行

公司剛好是分散式架構，對於分散式算是有一定經驗，有幸探討一下！

隨著分散式架構的大行其道，微服務系統遍地開花，資料庫也不得不採用分散式架構，這樣的大型架構事務不同於常規事務（事務在一個記憶體中，不需要訊息傳遞等），常常會引起資料不一致的業務問題，而解決的辦法就是使用分散式事務！

分散式事務通常的解決方案有四種:

1，基於XA的協議的兩階段提交方案！（兩個本地提交，一個協調者）

2，TCC事務控制（Try、Confirm、Cancel可算是三步吧）

3，基於訊息的最終一致性事務方案！

4，GTS，阿里的分散式事務解決方案！

既然本文問得是TCC，那就來詳細看下TCC究竟是啥玩意？

TCC:是一種分散式事務解決方案，一般操作分為try，confirm，cancel三步，即業務準備工作完成，確認業務提交，發現問題實現業務回滾！

事務發起的時候，業務方向事務協調器註冊，啟動事務，所有業務呼叫事務的try操作，完成階段一，然後事務協調器根據業務操作的完成情況，判斷執行是confirm或者cacel操作！

TCC將本地事務和聯合排程結合起來，達到分散式事務的目的，實現資料的一致性！保證大資料量的快速提交！

當然，TCC也存在不足:

1，對應用侵入性大:使用者需要在每個涉及事務的地方，自行實現try，confirm，cancel介面，開發複雜！

2，實現難度大:需要根據情況，做冪等性判斷，按照不同的失敗原因定製不同的回滾方案！

儘管如此，TCC作為一種效能良好的分散式事務解決方案，在很多大型網際網路公司都有廣泛的應用！

我們公司現在採用的是基於訊息的分散式事務，開發難度低，但是冪等性，訊息死亡等問題還是沒有良好的解決方案！

總的來說分散式事務因為跨服務，跨應用，還有很大的資料安全和一致性問題，還是慎用啊！