近些年微服務越來越愈來愈火爆，各種各樣架構與部件的發生，也是為微服務的開發設計給予了便捷。
眾所周知，每一個微服務全是一個相匹配的小服務項目，好幾個服務項目中間可以方便快捷的實現作用的組成，來產生作用更強有力的服務項目。服務間信息與布署全是獨立自主的，那樣常見故障還可以保證互相防護?？墒沁@也提供了分布式應用都是會應對的問題：
怎樣保證好幾個服務項目間的事務？怎么才能使實際操作的原子性、一致性等獲得保證？
針對傳統式的應用程序開發與布署，可以根據信息的事務來保證說白了的ACID,而微服務的情景下，數據庫查詢就心有余而力不足了。
這個時候，2PC、3PC輪流出場，來處理這種的問題。但很多情景下，大家按照自身的真正必須，并不一定純的2PC，例如你只關注數據信息的原子性與最后一致性，那2PC環節的堵塞就是你不可以承受的，那么就有聰明人想起了一種新的方法。便是大家今日想說的柔性事務TCC。
什么叫柔性事務TCC？
大家今日說的柔性事務，「柔」主要是相對性于「傳統式」ACID的剛來講，柔性事務只要遵循BASE標準。而TCC是柔性事務的一種完成。TCC是三個首字母大寫，Try-Confirm-Cancel，實際敘述是將全部實際操作分成上邊這三步。2個微服務間與此同時開展Try，在Try的環節會開展數據信息的校檢，查驗，資源的預建立，假如都取得成功便會各自開展Confirm，假如兩者都取得成功則全部TCC事務進行。假如Confirm時有一個服務項目有什么問題，則會轉為Cancel，等同于開展Confirm的反向實際操作。
全部柔性事務有多種多樣完成的觀念，例如：
實際應用
以前的新項目研發中，大家也是有相似的情景必須保證2個微服務間的一致性，依據實際的情景必須，使用了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) {
根據相似的架構，可以較為便捷的符合大家的業務流程應用情景。熱烈歡迎留言板留言填補你在分布式系統的情景中是根據哪些方法來保證一致性的。
補充說明:
原文中照片來自「支付寶錢包構架與技術性」文本文檔，有興趣的朋友們可以自主檢索獲得該文件。
End
