简单题，在校招和初级工程师中有可能遇到。
在这个场景之下，可以举例自己用分布式锁解决过的问题，并且将话题引导过去自己的项目经历上。
简单题，分布式锁算是难题，但是这个问题只是泛泛而谈倒也还好。在校招中不常见，但是在社招，尤其是目标公司是分布式架构或者微服务架构，那么这个部分就会问的很多。
你要通过讨论一般的分布式锁的实现要点来刷亮点。
简单题，很少问，因为这个东西是一些人总结出来的私货，还不是业界公认的点。
在回答这个问题的时候，你可以深入讨论续约的问题，赢得竞争优势。
基础理论题。大多数面试都不会要求你给出严谨的证明，而只是大概谈一谈。要想刷出亮点，你就需要进一步讨论不同场景下选择哪两个，并且进一步结合不同中间件的选择的 CAP 来深入讨论。
难题，在校招、初中级岗位的面试中，很少会问这么抽象的问题，一般都是具体问某个场景下怎么解决数据一致性的问题。
你在这个问题之下，要把握住：并发问题和部分失败是数据一致性问题难以解决的两个根源。而部分失败，在当下的分布式环境下是一个无法解决的问题。你在面试中能够阐释清楚这些理论就足以证明你对分布式系统有非常深刻的理解了。
简单题，校招不太常问，除非你装逼说自己会写分布式锁。社招有使用分布式锁经验的候选人容易遇到这个问题。
反正记住在跟分布式锁有关的问题下，装逼就不要忘了提分布式锁的续约问题。
简单题，校招不常见，因为校招生没有实践经验。社招比较常见。
很多人在使用分布式锁的时候其实都不会去考虑怎么解决这个问题，只是说设置一个足够长的过期时间，寄希望于不会出现这种情况。
而你要装逼，就要指出最好就是借助续约机制，避免出现分布式锁过期而业务还没结束的情况。
简单题，社招可能遇到，校招不太可能，因为校招没经验。
你在回答这个问题的时候，要深入讨论续约中可能出现的问题，以及对应的解决方案。
简单题，一般出现在社招，校招不会问——毕竟你没写过分布式锁。
在这个问题之下，可以深入讨论业务方中断业务的问题。
简单题。这种纯理论，有些面试官很喜欢在校招的时候问，虽然我觉得问校招的人没任何意义。社招问得更多。
在这里，你可以根据自己的理解，讲一下 BASE 在自己的系统里面的具体体现，以及使用 BASE 的时候的注意事项。
简单题。校招和社招都有可能问到，属于难者不会会者不难的题。
简单题，这就是问个概念，在任何层级的面试中都有可能遇到。你可以把这个问题看做一个信号，面试官准备跟你深入讨论分布式事务的信号。
类似地，在这种起点问题下你就要尽可能提及多的知识点，而后引导面试官提问。而后你也可以进一步提及自己在实践中解决过的分布式事务问题。
难题，热题，热过迪丽热巴的题。难在两方面：解决方案多，每一种方案都有点难，尤其是它们在各种异常情况下的处理方案。
当然在这个问题之下，你可以不用提及非常多的细节，只需要给出结论，等面试官追问就可以。而后你可以谈谈自己使用过的方案，刷一个经验丰富的人设。
简单题，在各个层级的面试中容易遇到，尤其是校招。
那在这个问题之下，你可以从两个角度刷亮点：一个角度是错误处理，也就是任何一个步骤、任何一个参与者失败了怎么办；另外一个角度是深入讨论 2PC 和 ACID，结论自然是 2PC 一点都没实现 ACID。
那在这个问题之下，你可以从两个角度刷亮点：一个角度是错误处理，也就是任何一个步骤、任何一个参与者失败了怎么办；另外一个角度是深入讨论 3PC 和 ACID，结论自然是 2PC 一点都没实现 ACID。
那在这个问题之下，你可以从两个角度刷亮点：一个角度是错误处理，也就是任何一个步骤、任何一个参与者失败了怎么办；另外一个角度是深入讨论 TCC 和 ACID，结论自然是 TCC 一点都没实现 ACID。
略难的题。一般校招比较少问，或者说面试官水平一般的时候不太会问这个内容，面试公司如果有大规模分布式系统，有非常复杂的分布式事务，那么面这个问题的几率就会大增。
相比两阶段提交、三阶段提交和 TCC，SAGA 在实践中用得比较少。
类似于别的分布式事务方案，在SAGA面试中，同样是通过讨论 SAGA 事务的错误处理，以及 SAGA 事务和 ACID 的关系来赢得竞争优势。当然后续我要是提供了基于事件驱动的 SAGA 框架的案例，你就可以用我的案例来刷超级亮点。
略难一点，而且这个问题不仅仅是出现在分布式事务场景下，但凡你的业务有一定要发送消息成功的场景，面试官就会问。
在面试中，你可以提及自己研发一个 SDK，提供了本地消息表的通用实现，统一解决补偿任务、监控等问题。
简单题。事实上在面试中比较少问这个问题，更加多的是问本地消息表。
在这个问题之下，你要刷亮点，还是要落在讨论本地消息表的错误处理，以及该方案是否支持 ACID。
略难的题，基本上任何面试中都有可能问到。
很多人都能回答出来借助唯一索引来保证幂等，但是这个回答有两个问题：部分失败问题，不高端没有竞争力。所以这里会教你使用布隆过滤器和Redis来做幂等。
简单的概念题，基本上也就是校招之类的会问一下了。
在这个问题之下，你可以罗列一下自己使用过幂等的场景。注意的是，这里最好列举你项目里面最牛逼的，能够让你刷出亮点的场景。
简单题，但是如果唯一索引不能做成业务本地事务的一部分，那么这个题就有点难了。基本上在校招或者初级工程师岗位的面试中会见到。
回答这个问题，你刷亮点就是要揭露出来，这个方案之所以靠谱，没有部分失败的问题，都是借助本地事务达成的。而如果操作唯一索引并不能作为本地事务的一部分，那么这个方案就同样有部分失败的问题。
略难的题，难点就在于要考虑解决部分失败的问题。这个问题很少问，因为一般来说考察幂等都是考察借助唯一索引来实现幂等。
略难的题，在社招里面可能会遇到，校招不太常见。
实际上，如果你的项目经历中涉及到了幂等的问题，那么你可以考虑将这个解决思路作为你的面试案例。
你在面试的时候，要注意深入讨论部分失败的，并且要强调 Redis 的效果是能快速拒绝重复请求，而非重复请求最终都还是要落到数据库上的。
略难的题，因为布隆过滤器本身也是一个热点，所以在面试中遇到的概率要大一些。校招和社招都有可能遇到。
在这个问题之下，要深入讨论布隆过滤器的假阳性问题，以及部分失败的问题。
略难的题，你如果不主动提，几乎不会被问到。
实际中这个方案几乎不会用，只有在超大数据量，超高并发的场景下才会考虑。而且它会引入更多的复杂度，但是收益又很小。
在面试中，这个方案看起来就非常牛逼了，很适合装逼刷亮点。大部分面试官没这个能耐看出这是一个华而不实的方案。
