分布式事务解决方案TCC
预处理尝试:进行业务检查和资源预留。
确认:做业务确认。
撤消取消:执行回滚操作。
TM将首先启动所有分支事务的try操作。如果任何分支事务的try操作失败，TM将启动所有分支事务的Cancel操作。如果尝试全部成功，TM将启动所有分支事务的确认操作。其中，如果确认和取消操作失败，TM将重试。
1)try阶段是做业务检查(一致性)和资源预留(隔离)。
2)2)确认阶段是一个确认提交，并且Try阶段中的所有分支事务都被成功执行以开始确认。
通常，在使用TCC时，相信在确认阶段不会出现错误。只要尝试成功，确认就会成功。如果确认时出现错误，请重试或手动操作。
3)取消阶段是在业务执行错误需要回滚时，取消其他未失败的分支交易，即释放预留资源。
一般来说，TCC的取消阶段也被认为是成功的，如果有错误，则引入重试或手动处理。
以下框架都支持TCC全局事务。目前阿里seata拥有庞大的用户群，github的star数量也遥遥领先，seata的实际源代码也会逐步增加。
在Try阶段，假设向服务A发送了一个Try请求，由于网络原因网络超时。此时协调器收到网络超时的响应，需要在第二步取消。然而，服务A在尝试阶段根本没有成功，这导致了数据不一致。
解决问题的关键是如何在Try阶段识别服务A是否执行成功，如果成功则执行commit，如果失败则执行空回滚。您可以添加一个分支事务记录表来记录分支事务和全局事务id。当请求超时时，您可以通过这个表查看分支事务，如果您执行了Try，您将记录它。不做就空白回卷。
主要是在尝试阶段。通过增加交易状态表进行确认或取消前的查询。
更严格的需求是添加分布式锁。
因为超时等原因，在try之前执行cancel，这是一个挂起问题。
解决办法是增加一个支行交易记录表，先查询。如果已经执行了cancel，将不会执行try。