“如何解决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带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！