一线大厂面试真题——如何解决TCC中的悬挂问题

目录

问题解析

问题解答

---

问题解析

TCC是分布式事务问题里面的解决方案，一般在应聘互联网公司的时候问的比较多。实际上，在TCC这个事务解决方案里面，除了悬挂问题以外，还有空回滚、幂等性需

要考虑。

但是我们在应用的时候都是采用一些成熟的框架，比如Seata，这些框架本身就帮我们解决了。

导致大部分人不知道这个问题的意思。

所谓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悬挂问题的背景，它确实是每个成熟的高级开发必须要了解的细节。

因为有可能会造成比较严重的生产事故。

了解了背景之后，我们应该如何解决呢？下面来看看高手的回答。

问题解答

对于悬挂问题，我认为只需要保证Cancel接口执行完以后，Try接口不允许在执行就可以了。

所以，我们可以在Try接口里面，先判断Cancel接口有没有执行过，如果已经执行过，就不再执行。

是否执行过的这个判断，可以在事务控制表里面插入一条事务控制记录来标记这个事务的回滚状态。

然后在Try接口中只需要读取这个状态来判断就行了。