TCC（Try-Confirm-Cancel），则是将业务逻辑分成try、confirm/cancel两个阶段执行，具体介绍见TCC事务机制简介。其事务处理方式为：
1、 在全局事务决定提交时，调用与try业务逻辑相对应的confirm业务逻辑；
2、 在全局事务决定回滚时，调用与try业务逻辑相对应的cancel业务逻辑。
TCC事务是通过执行Cancel业务来达到回滚效果的。仔细分析一下，这里暗含一个事实：只有生效的Try业务操作才需要执行对应的Cancel业务操作。换句话说，只有Try业务操作所参与的RM本地事务被commit了，后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作；否则，如果Try业务操作所参与的RM本地事务被rollback了，后续TCC全局事务回滚时就不能执行其Cancel业务，此时若盲目执行Cancel业务反而会导致数据不一致。其次，Confirm/Cancel业务操作必须保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作，其参与的RM本地事务也必须被commit。TCC事务框架需要在确切的知道所有Confirm/Cancel业务操作参与的RM本地事务都被成功commit后，才能将标记该TCC全局事务为完成。如果TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的状态，就会造成全局事务不一致。最后，未完成的TCC全局，TCC事务框架必须重新尝试提交/回滚操作。重试时会再次调用各TCC服务的Confirm/Cancel业务方法。如果某个服务的Confirm/Cancel业务之前已经生效（其参与的RM本地事务已经提交），重试时就不应该再次被调用。否则，其Confirm/Cancel业务方法被多次调用，就会有“服务幂等性”的问题。

TCC（Try-Confirm-Cancel），则是将业务逻辑分成try、confirm/cancel两个阶段执行，具体介绍见TCC事务机制简介。其事务处理方式为：
1、 在全局事务决定提交时，调用与try业务逻辑相对应的confirm业务逻辑；
2、 在全局事务决定回滚时，调用与try业务逻辑相对应的cancel业务逻辑。
TCC事务是通过执行Cancel业务来达到回滚效果的。仔细分析一下，这里暗含一个事实：只有生效的Try业务操作才需要执行对应的Cancel业务操作。换句话说，只有Try业务操作所参与的RM本地事务被commit了，后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作；否则，如果Try业务操作所参与的RM本地事务被rollback了，后续TCC全局事务回滚时就不能执行其Cancel业务，此时若盲目执行Cancel业务反而会导致数据不一致。其次，Confirm/Cancel业务操作必须保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作，其参与的RM本地事务也必须被commit。TCC事务框架需要在确切的知道所有Confirm/Cancel业务操作参与的RM本地事务都被成功commit后，才能将标记该TCC全局事务为完成。如果TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的状态，就会造成全局事务不一致。最后，未完成的TCC全局，TCC事务框架必须重新尝试提交/回滚操作。重试时会再次调用各TCC服务的Confirm/Cancel业务方法。如果某个服务的Confirm/Cancel业务之前已经生效（其参与的RM本地事务已经提交），重试时就不应该再次被调用。否则，其Confirm/Cancel业务方法被多次调用，就会有“服务幂等性”的问题。