TCC（Try-Confirm-Cancel）是一种常见的分布式事务解决方案，将一个事务拆分成三个步骤：
T(Try)：业务检查阶段，这阶段主要进行业务校验和检查或资源预留；也可能是直接进行业务操作。
C(Confirm)：业务确认阶段，这阶段对Try阶段校验的业务或预留的资源进行确认。
C(Cancel)：业务回滚阶段，这阶段和上面的C(Confirm)是互斥的，用于释放Try阶段预留的资源或业务。
解决TCC幂等问题：
为了保证TCC二阶段提交重试机制不会引发数据一致性，要求TCC的二阶段Confirm和Cancel接口保证幂等，这样不会重复使用或者释放资源。
如果幂等控制没有做好，很有可能导致数据不一致等问题。
解决思路是上述分支事务记录中增加执行状态，每次执行前都查询该状态。
解决TCC中悬挂问题：
悬挂就是对于一个分布式事务，其二阶段Cancel接口比Try接口先执行。
出现原因就是在调用分支事务Try时，由于网络发生拥堵，造成了超时，TM就会通知BM回滚该分布式，可以能回滚完成后，Try请求才到达参与真正执行，而一个Try方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就成为悬挂，及业务资源预留后无法继续处理。
解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，判断分支事务记录表中是否已经有二阶段事务记录，如果有责不执行Try。
