如何解决 TCC 中的悬挂问题

TCC 是分布式事务问题里面的解决方案，一般在应聘互联网公司的时候问的比较多。实际上，在 TCC 这个事务解决方案里面，除了悬挂问题以外，还有空回滚、幂等性需要考虑。但是我们在应用的时候都是采用一些成熟的框架，比如 Seata，这些框架本身就帮我们解决了。导致大部分人不知道这个问题的意思。

TCC

所谓 TCC，其实就是（Try-Confirm-Cancel），也就是把一个事务拆分成两个阶段，类似于传统的 XA 事务模型。

• Try 这个阶段，是实现业务的检查，预留必要的业务资源。
• Confirm，真正执行业务逻辑，只需要使用 try 阶段预留的业务资源进行处理就行。
• Cancel，如果事务执行失败，就通过 cancel 方法释放 try 阶段预留的资源。

在 TCC 事务模式下，我们通过一个事务协调器来管理多个事务，每个事务先执行 try 方法。当所有事务参与者的 try 方法执行成功，就执行 confirm 方法完成真正逻辑的执行，一旦任意一个事务参与者出现异常，就通过 cancel 接口触发事务回滚，释放 Try 阶段占用的资源。

悬挂问题

很显然，这是一个最终一致性的实现方案，因此当 Try 执行成功，就必须确保 Confirm执行成功。当 Try 执行失败，就必须确保 Cancel 实现资源释放。而面试题中提到悬挂问题，指的是 TCC 执行 Try 接口出现网络超时时候，使得 TCC 触发 Cancel 接口回滚，但可能在回滚之后，这个超时的 Try 接口才被真正执行，也就导致 Cancel 接口比 Try 接口先执行。从而造成 Try 接口预留的资源一直无法释放，这种情况就是悬挂。以上就是 TCC 悬挂问题的背景，它确实是每个成熟的高级开发必须要了解的细节。因为有可能会造成比较严重的生产事故。