转载

时隔半年，再面头条……

时隔半年，再次来到这个战场，情景居然和半年前一模一样，一面流程模式还是非常固定的，分为下面这三个步骤。

介绍自己->技术提问->算法题

介绍自己和算法题就不多说了，还记得里面问的最多的问题给大家情景再现一下。

面试官：你们现在使用的微服务么？

Me：是的，我们用的 Spring Cloud。( Me 心理活动 ：早准备好了 Spring Cloud 的问题，来吧，窃喜)

面试官：那你和我说说你们怎么用的分布式事务？( Me 心理活动 ：擦，这哥们不按套路出牌啊)

Me：好的，说到分布式事务，还是需要先说一下 CAP 的，在微服务的大前提下，一定是遵循 CAP，所以我们分布式事务最终解决的问题是最终一致性。我们主要用消息机制驱动任务的提交和失败的补偿。

面试官：那你了解其他的方案么？或者你为什么用这种方案？

Me：分布式事务的方案很多，比如2PC，采用两段的提交方式，第一次是 PreCommit(预提交)用于锁定资源，第二次是 Commit(确认提交)，这种方式相对比较简单，但是其事务是阻塞型的，导致扩展性不是很好；其次比较常用的是 TCC 的方式，这种就对 2PC 的方式进行了改进，把事务放在业务层去做，当然这种方式对于补偿的机制还是不够完善；所以充分考虑到我们复杂的服务之间的依赖，最终选择了消息驱动事务提交，维护消息的状态同时监听每一个请求的成功状态。

面试官：恩，那么如果没有收到消息怎么处理呢？

Me：即便是我们充分做了补偿机制还是会有收不到消息的情况，这时候我们会再做两次补偿，一次是针对失败的再次触发一轮重试，一次是离线的数据校对。

面试官：恩，好的，那我们聊另一个话，你用过分布式锁吗？

Me 心理活动：呀，这怎么不停的连环炮了呀，哎，不过幸亏我仔仔细细准备了分布式事务的内容不然肯定跪了。

面试问题还很多，就不一一和大家说了，不过说到知识点啊，不仅仅要了解自己当前的技术，同时也一定要了解横向的技术对比，这样才能游刃有余的应对面试官的连环炮( 偷偷的告诉你，我进入了二面啦，下文中关于这个分布式事务的内容还有进阶干货 )。

不过这知识也不是一蹴而就的，深度和广度我们都要兼顾，慢慢来，下面有一个技术图谱，里面罗列比较全面的技术知识点，你可以看下。

时隔半年，再面头条……