TCC是应用层的2PC(2 Phase Commit, 两阶段提交)，
如果你将应用看做资源管理器的话。
详细来说，TCC每项操作需要做的事情如下：
1、Try：尝试执行业务。
- 完成所有业务检查(一致性)
- 预留必须业务资源(准隔离性)
2、Confirm：确认执行业务。
- 真正执行业务
- 不做任何业务检查
- 只使用Try阶段预留的业务资源
3、Cancel：取消执行业务
- 释放Try阶段预留的业务资源
个完整的TCC事务参与方包括三部分：
- 主业务服务：主业务服务为整个业务活动的发起方，如前面提到的组合支付场景，支付系统即是主业务服务。
- 从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。由于Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。
- 业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。
可见整个TCC事务对于主业务服务来说是透明的，其中业务活动管理器和从业务服务各自干了一部分工作
TCC的优点和限制
TCC事务的优点如下：
- 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。
- TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交
- 规避了数据库层的2PC性能低下问题。
- 实时业务，执行时间较短的业务
- 强一致性的业务
TCC事务的缺点，主要就一个：
- TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。
1、Try：尝试执行业务。
- 完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
- 预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。
2、Confirm：确认执行业务。
- 真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
- 不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
- 只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。
3、Cancel：取消执行业务
- 释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。
小结：到底要不要使用TCC到底要不要使用TCC事务，取决于以下几点：
- 是否真正有保证跨应用业务操作的原子性需求。
- 研发上能否投入资源开发相对应的TCC接口。
- 当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。
一个问题，如果TCC事务在Try阶段所有参与方(从业务服务)成功了，但是Confirm阶段部分参与方(从业务服务)成功，如何处理？