分布式事务之TCC处理

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

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

空回滚

     原因&＃xff1a; 没有调用try 方法&＃xff0c;直接调用cancel方法

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

悬挂

     原因&＃xff1a;在事务中&＃xff0c;cancel接口比try接口先执行了

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

幂等

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

      解决方案&＃xff1a;“分支事务记录“表中增加执行状态&＃xff0c;每次执行前都查询该状态