材料摘自龙果学院：http://www.roncoo.com/
一个完整的TCC事务参与方包括三部分：
- 主业务服务：主业务服务为整个业务活动的发起方，如前面提到的组合支付场景，支付系统即是主业务服务。
- 从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。由于Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。
- 业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。
可见整个TCC事务对于主业务服务来说是透明的，其中业务活动管理器和从业务服务各自干了一部分工作。
Try: 尝试执行业务
完成所有业务检查（一致性）
预留必须业务资源（准隔离性）
Confirm: 确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作满足幂等性
Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作满足幂等性
TCC的优点和限制
TCC事务的优点如下：
- 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。
- TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
- TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。