使用spring-cache让我的接口性能瞬间提升了，面试必问

前言

最近一段时间发现经常看到很多人，对Spring源码比较感兴趣，日常开发中，无论你做什么什么项目，大部分都离不开Spring生态的那一套东西，所以很多人对Spring底层源码实现很感兴趣，但是有些从来没有接触过源码的开发者，在看Spring源码的过程中确实及其难受的，为什么，大部分人看源码基本都是debug一点一点去看的，最后发现，越追越离谱，越追越深，到最后都追到JDK源码了，也没有明白是什么意思！

对于学习源码，我的看法是，先去完全的熟悉它的用法，想一下如果让你来实现，你会怎么实现！有了这些想法之后，再去看源码去印证你自己的观点，远比你自己去死扣源码快的多。

而且，我问过一些读者还有同事，我发现有很多人，看源码容易陷入一个误区，就是刚开始看源码就死扣着一个细节不放，非得搞懂，我并不是说这样看源码有什么不对，但是在没有对整个框架有一个全局了解的情况下，不要这样看，你应该先把它的大体框架给搞清楚，在后再分功能一步一步的了解每一个功能项！这样做，首先你对整个框架的架构有了一个模糊的认识，再扣细节的途中有时候即使你不知道这个代码在干什么，你也隐约能猜出来，再通过debug 与自己的猜测相互印证，最终达到事半功倍的效果。当然这个建议只针对刚开始看源码的同学，如果你看的源码很多了，那么你肯定又自己的一套学习方法，可以的话，可以在评论区分享一下。

为了帮助一些萌新们或者想要了解Spring源码的小伙伴，我会把Spring的一些大体逻辑分析一下，让你了解整个Spring的骨架！

常见的分布式事务场景

分布式事务其实就在我们身边，你一直在用，但是你却一直不注意它。

转账

扣你账户的余额，增加别人账户余额，如果只扣了你的，别人没增加这是失败；如果没扣你的钱别人也增加了那银行的赔钱。

下订单/扣库存

电商系统中这是很常见的一个场景，用户下单成功了，店家没收到单，不发货；用户取消了订单，但是店家却看到了订单，发了货。

分库分表场景

当我们的数据量大了之后，我们可能会部署很多独立的数据库，但是你的一个逻辑可能会同时操作很多个数据库的表，这时候该如何保证所有的操作要么成功，要么失败。

分布式系统调用问题

微服务的拆分让各个系统各司其职，但是带来的也有很多痛苦，一个操作可能会伴随很多的外部请求，如果某一个外部系统挂掉了，之前操作已完成的这些是否需要回滚。

针对上面这些问题，我们前面学过的数据库4大特性：ACID 似乎在这里想要达到就变得很困难，单机情况下你还可以通过锁和日志机制来控制数据，在分布式场景又该如何实现呢？在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。尽管有这么多工程细节需要考虑，但分布式事务最核心的还是其 ACID 特性，只是这种 ACID 变换了场景。

分布式理论

CAP 定理

传统的 ACID 模型肯定无法解决分布式环境下的挑战，基于此加州大学伯克利分校 Eric Brewer教授提出 CAP 定理，他指出 现代 WEB 服务无法同时满足以下 3 个属性：

• 一致性(Consistency) ： 所有的客户端都能返回最新的操作。
• 可用性(Availability) ： 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用，操作依然可以完成。

关于一致性的理解后面分出来三个方向：

• 强一致：任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。
• 弱一致：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
• 最终一致：不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

关于一致性的理解不同，后面对于 CAP 理论的实现就有所不同。

另外 Eric Brewer教授指出现代 WEB 服务无法同时满足这 3 个属性，说的是无法同时满足，那这是为什么呢？

如果在某个分布式系统中无副本，那么必然满足强一致性，同时也满足可用性，但是如果这个数据宕机了，那么可用性就得不到保证。

如果一个系统满足 AP，那么一致性又得不到保证。所以 CAP 原则的精髓就是要么 AP，要么 CP，要么 AC，但是不存在 CAP。

BASE 定理

基于前面提到的 CAP，反正我们都无法同时满足CAP，设计系统的最高目的就是让他跑下去不出错，那么是不是可以不要求强一致性，最终让他一致即可。所以后面又提出来了 BASE 定理：

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

基于现在大型分布式系统的复杂性，我们无法保证服务永远达到999，那么是否可以取舍，核心服务达到999，非核心服务允许挂为了保全核心服务。另外在非核心服务 down 机过程中允许系统暂时出现不一致但是这个不一致并不影响系统的核心功能使用。

最终系统恢复，所有服务一起修复数据，最终达到一致的状态。

业内通常把严格遵循 ACID 的事务称为刚性事务，而基于 BASE 思想实现的事务称为柔性事务。柔性事务并不是完全放弃了 ACID，仅仅是放宽了一致性要求：事务完成后的一致性严格遵循，事务中的一致性可适当放宽。

常见的分布式事务实现方案

分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务。柔性事务：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。

• 刚性事务：X