分布式事务之TCC处理

只要try成功，认为confirm成功，如果confirm出错，需要重试或人工处理

cancal阶段在业务执行错误需要回滚的状态下，会执行分支事务的业务取消，预留资源释放。认为cancel也是成功的，失败要重试或人工处理

空回滚

     原因： 没有调用try 方法，直接调用cancel方法

     解决方案：解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分 布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会 插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

      

悬挂

     原因：在事务中，cancel接口比try接口先执行了

     解决方案：如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

 

幂等

      原因：为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题

      解决方案：“分支事务记录“表中增加执行状态，每次执行前都查询该状态