TCC实际上是Try、Confirm和Cancel的简称，将事务的提交过程分为try-confirmcancel三个阶段。try阶段完成业务检查、预留业务资源；confirm阶段使用预留的资源执行业务操作；cancel阶段取消执行业务操作，释放预留的资源。TCC和两阶段提交有类似之处，都需要事务的参与者实现对应的接口。TCC的事务参与者必须实现try、confirm、cancel三个接口。TCC事务的流程如下。
1）事务协调器发起事务请求，调用所有事务参与者的try接口完成资源的预留，这时候并没有真正执行业务，而是为后面具体要执行的业务预留资源。如果该阶段有参与者的try接口返回错误，则无法预留资源。如果资源不够，事务协调器则调用所有参与者的cancel接口回滚预留的资源。事务协调器有幂等和重试机制，以确保参与者的cancel接口被调用并回滚预留的资源。
2）如果事务协调器发现所有参与者的try接口都返回成功，则调用所有参与者的confirm接口。参与者不会再次检查资源，而是直接依据预留的资源进行具体的业务操作。如果协调器发现所有参与者的confirm接口都成功了，则分布式事务结束。如果协调器发现有些参与者的confirm接口返回失败，则调用所有参与者的cancel接口进行资源回滚。如果由于网络原因，协调器没有收到回执，则会进行重试。如果在既定的重试次数或者时间段内依然失败，协调器则会触发其他参与者的cancel接口进行资源回滚。如果协调器一直没有收到确认，则会保留当前事务的状态，方便后续的事务补偿操作，如收到参与者返回后进行回滚操作，或者人工介入进行对应的数据修复，确保数据的最终一致。TCC采用了资源加锁粒度较小的柔性事务，将一个大的事务划分为多个独立的小的事务。每一个小的事务采取资源预留的机制进行事务处理。对于整个事务链来说，无法做到原子级别的事务提交，所以也就无法保证某一时刻的数据一致性，只能保证最终的数据一致性。
