轉載自：http://www.bytesoft.org/
TCC事務機制簡介
關於TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland於2007年發表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。在該論文中，TCC還是以Tentative-Confirmation-Cancellation作為名稱；正式以Try-Confirm-Cancel作為名稱的，可能是Atomikos（Gregor Hohpe所著書籍《Enterprise Integration Patterns》中收錄了關於TCC的介紹，提到了Atomikos的Try-Confirm-Cancel，並認為二者是相似的概念）。
國內最早關於TCC的報道，應該是InfoQ上對阿里程立博士的一篇采訪。經過程博士的這一次傳道之后，TCC在國內逐漸被大家廣為了解並接受。相應的實現方案和開源框架也先后被發布出來，ByteTCC就是其中之一。
TCC事務機制相對於傳統事務機制（X/Open XA），其特征在於它不依賴資源管理器(RM)對XA的支持，而是通過對（由業務系統提供的）業務邏輯的調度來實現分布式事務。對於業務系統中一個特定的業務邏輯S，其對外提供服務時，必須接受一些不確定性，即對業務邏輯執行的一次調用僅是一個臨時性操作，調用它的消費方服務M保留了后續的取消權。如果M認為全局事務應該rollback，它會要求取消之前的臨時性操作，這就對應S的一個取消操作。而當M認為全局事務應該commit時，它會放棄之前臨時性操作的取消權，這對應S的一個確認操作。 每一個初步操作，最終都會被確認或取消。因此，針對一個具體的業務服務，TCC事務機制需要業務系統提供三段業務邏輯：初步操作Try、確認操作Confirm、取消操作Cancel。
1. 初步操作（Try）
TCC事務機制中的業務邏輯（Try），從執行階段來看，與傳統事務機制中業務邏輯相同。但從業務角度來看，是不一樣的。TCC機制中的Try僅是一個初步操作，它和后續的次確認一起才能真正構成一個完整的業務邏輯。因此，可以認為[傳統事務機制]的業務邏輯 = [TCC事務機制]的初步操作（Try） + [TCC事務機制]的確認邏輯（Confirm）。TCC機制將傳統事務機制中的業務邏輯一分為二，拆分后保留的部分即為初步操作（Try）；而分離出的部分即為確認操作（Confirm），被延遲到事務提交階段執行。
TCC事務機制以初步操作（Try）為中心，確認操作（Confirm）和取消操作（Cancel）都是圍繞初步操作（Try）而展開。因此，Try階段中的操作，其保障性是最好的，即使失敗，仍然有取消操作（Cancel）可以將其不良影響進行回撤。
2. 確認操作（Confirm）
確認操作（Confirm）是對初步操作（Try）的一個補充。當TCC事務管理器認為全局事務可以正確提交時，就會逐個執行初步操作（Try）指定的確認操作（Confirm），將初步操作（Try）未完成的事項最終完成。
3. 取消操作（Cancel）
取消操作（Cancel）是對初步操作（Try）的一個回撤。當TCC事務管理器認為全局事務不能正確提交時，就會逐個執行初步操作（Try）指定的取消操作（Cancel），將初步操作（Try）已完成的事項全部撤回。
在傳統事務機制中，業務邏輯的執行和事務的處理，是在不同的階段由不同的部件來處理的：業務邏輯部分訪問資源實現數據存儲，其處理是由業務系統負責；事務處理部分通過協調資源管理器以實現事務管理，其處理由事務管理器來負責。二者沒有太多交互的地方，所以，傳統事務管理器的事務處理邏輯，僅需要着眼於事務完成（commit/rollback）階段，而不必關注業務執行階段。而在TCC事務機制中的業務邏輯和事務處理，其關系就錯綜復雜：業務邏輯（Try/Confirm/Cancel）階段涉及所參與資源事務的commit/rollback；全局事務commit/rollback時又涉及到業務邏輯（Try/Confirm/Cancel）的執行。其中關系，本站將另行撰文詳細介紹，敬請關注！
參考文獻：
1. http://www.infoq.com/cn/interviews/soa-chengli
2. https://cs.brown.edu/courses/cs227/archives/2012/papers/weaker/cidr07p15.pdf
3. http://www.enterpriseintegrationpatterns.com/patterns/conversation/TryConfirmCancel.html
ByteTCC介紹
ByteTCC是一個基於TCC（Try/Confirm/Cancel）機制的分布式事務管理器。兼容JTA，可以很好的與Spring等容器進行集成。特性：
1、支持Spring容器的聲明式事務管理；
2、支持普通事務、TCC事務、業務補償型事務等事務機制；
3、支持多數據源、多應用、多服務器事務傳播的分布式事務協調，滿足多種不同的事務處理的需求；
4、支持dubbo服務框架；
項目地址：https://github.com/liuyangming/ByteTCC/
用戶指南：https://github.com/liuyangming/ByteTCC/wiki
ByteJTA介紹
ByteJTA Transaction Manager是一個基於XA兩階段提交的分布式事務管理器。
項目地址：https://github.com/liuyangming/ByteJTA/