实现
一个完整的业务活动由一个主业务服务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务服务提供TCC型业务操作
业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作
成本
实现TCC操作的成本
业务活动结束时confirm或cancel操作的执行成本
业务活动日志成本
适用范围
强隔离性、严格一致性要求的业务活动
适用于执行时间较短的业务（比如处理账户、收费等业务）
用到的服务模式
TCC操作、幂等操作、可补偿操作、可查询操作
方案特点
不与具体的服务框架耦合（在RPC架构中通用）
位于业务服务层，而非资源层
可以灵活选择业务资源的锁定粒度
TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）
行业应用案例
支付宝XTS（蚂蚁金融云的分布式事务服务DTS）
Try: 尝试执行业务
完成所有业务检查(一致性)
预留必须业务资源(准隔离性)
Confirm:确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作要满足幂等性
Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作要满足幂等性
与2PC协议比较
位于业务服务层而非资源层
没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力
Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
较高开发成本
误区：很多人把两阶段型操作等同于两阶段提交协议2PC操作。其实TCC操作也属于两阶段型操作。
可补偿操作
do: 真正执行业务
完成业务处理
业务执行结果外部可见
compensate:业务补偿
抵销(或部分抵销)正向业务操作的业务结果
补偿操作满足幂等性
约束
补偿在业务上可行
由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控
（TCC操作中的Confirm操作和Cancel操作，其实也可以看作是补偿操作）
TCC框架github地址
https://github.com/changmingxie/tcc-transaction
流程图
如果try阶段异常则进入cancel阶段
如果try阶段成功则进入confirm阶段，且进入confirm阶段的事务只会向前推进。不会cancel。如果confirm失败则走恢复事务的流程。达到最大重试次数后则需要人工干预。
原文：https://blog.csdn.net/qq_27384769/article/details/79349847