《如何解决TCC中的悬架问题》！一个工作4年的Java程序员去京东面试，被问到这个问题。大家好，我是Mic，一名工作了14年的Java程序员。面试官想考察什么样的知识？我们该如何回答？问题分析TCC是分布式事务问题的解决方案，一般在应聘互联网公司的时候问的比较多。其实在TCC的事务解决方案中，除了暂停问题，还有空回滚和幂等性需要考虑。但是我们在应用的时候总是使用一些成熟的框架，比如Seata。这些框架本身就可以为我们解决问题。大多数人不知道这个问题是什么意思。所谓TCC其实就是（Try-Confirm-Cancel），也就是把一个事务拆分成两个阶段，类似于传统的XA事务模型。Try阶段是实现对业务的检查，预留必要的业务资源。确认一下，要真正执行业务逻辑，只需要使用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界面中，只需要读取这个状态就可以判断了。今天的分享到此结束。喜欢我的作品记得点赞收藏关注哦！！！版权声明：除特别声明外，本博客所有文章均采用CCBY-NC-SA4.0许可协议。转载请注明来自Mic带你学建筑！如果本文对您有帮助，请给个关注和点赞。您的坚持是我不断创作的动力。欢迎关注同名微信公众号获取更多技术干货！
