TCC, 是基于補償型事務的AP系統的一種實現, 具有最終一致性  下面以客戶購買商品時的付款操作為例進行講解: * Try: 完成所有的業務檢查(一致性),預留必須業務資源(準隔離性); 體現在本例中, 就是確認客戶賬戶余額足夠支付(一致性), 鎖住客戶賬戶, 商戶賬戶(準隔離性). * Confirm: 使用Try階段預留的業務資源執行業務(業務操作必須是冪等的), 如果執行出現異常, 要進行重試. 在這里就是執行客戶賬戶扣款, 商戶賬戶入賬操作. * Cancle: 釋放Try階段預留的業務資源, 在這里就是釋放客戶賬戶和商戶賬戶的鎖; 如果任一子業務在Confirm階段有操作無法執行成功, 會造成對業務活動管理器的響應超時, 此時要對其他業務執行補償性事務. 如果補償操作執行也出現異常, 必須進行重試, 若實在無法執行成功, 則事務管理器必須能夠感知到失敗的操作, 進行log(用于事后人工進行補償性事務操作或者交由中間件接管在之后進行補償性事務操作). # 優點 對比與前面提到的兩階段提交法, 有兩大優勢: * TCC能夠對分布式事務中的各個資源進行分別鎖定, 分別提交與釋放, 例如, 假設有AB兩個操作, 假設A操作耗時短, 那么A就能較快的完成自身的try-confirm-cancel流程, 釋放資源. 無需等待B操作. 如果事后出現問題, 追加執行補償性事務即可. * TCC是綁定在各個子業務上的(除了cancle中的全局回滾操作), 也就是各服務之間可以在一定程度上”異步并行”執行. # 注意事項 * 事務管理器(協調器)這個節點必須以帶同步復制語義的高可用集群(HAC)方式部署. * 事務管理器(協調器)還需要使用多數派算法來避免集群發生腦裂問題. # 適用場景 * 嚴格一致性 * 執行時間短 * 實時性要求高 舉例: 紅包, 收付款業務.