共计 1149 个字符，预计需要花费 3 分钟才能阅读完成。
“如何解决 TCC 中的悬挂问题”！
一个工作了 4 年的 Java 程序员，去京东面试，被问到这个问题。
大家好，我是 Mic，一个工作了 14 年的 Java 程序员
这个问题面试官想考查什么方面的常识？咱们又该怎么答复呢？
问题解析
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 接口中只须要读取这个状态来判断就行了。
总结
好了，明天的分享就到这里完结了。
如果喜爱我的作品，记得点赞、珍藏、关注！！！
版权申明：本博客所有文章除特地申明外，均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自
Mic 带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！
