1. 缓存的根本思维
很多敌人，只晓得缓存能够进步零碎性能以及缩小申请相应工夫，然而，不太分明缓存的实质思维是什么。
缓存的根本思维其实很简略，就是咱们十分相熟的空间换工夫。不要把缓存想的太高大上，尽管，它确实对系统的性能晋升的性价比十分高。
其实，咱们在学习应用缓存的时候，你会发现缓存的思维理论在操作系统或者其余中央都被大量用到。比方 CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。 再比方操作系统在 页表计划 根底之上引入了 快表 来减速虚拟地址到物理地址的转换。咱们能够把快表了解为一种非凡的高速缓冲存储器（Cache）。
回归到业务零碎来说：咱们为了防止用户在申请数据的时候获取速度过于迟缓，所以咱们在数据库之上减少了缓存这一层来补救。
当他人再问你，缓存的根本思维的时候，就把下面这段话通知他，我感觉会让他人对你另眼相看。
2. 应用缓存为零碎带来了什么问题
软件系统设计中没有银弹，往往任何技术的引入都像是把双刃剑。 你应用的形式切当，就能为零碎带来很大的收益。否则，只是费了精力不讨好。
简略来说，为零碎引入缓存之后往往会带来上面这些问题：
ps: 其实我感觉引入本地缓存来做一些简略业务场景的话，理论带来的代价简直能够疏忽，上面次要是针对分布式缓存来说的。
- 零碎复杂性减少：引入缓存之后，你要保护缓存和数据库的数据一致性、保护热点缓存等等。
- 零碎开发成本往往会减少：引入缓存意味着零碎须要一个独自的缓存服务，这是须要破费相应的老本的，并且这个老本还是很贵的，毕竟消耗的是贵重的内存。然而，如果你只是简略的应用一下本地缓存存储一下简略的数据，并且数据量不大的话，那么就不须要独自去弄一个缓存服务。
3. 本地缓存解决方案
先来聊聊本地缓存，这个理论在很多我的项目中用的蛮多，特地是单体架构的时候。数据量不大，并且没有分布式要求的话，应用本地缓存还是能够的。
常见的单体架构图如下，咱们应用 Nginx 来做 负载平衡，部署两个雷同的服务到服务器，两个服务应用同一个数据库，并且应用的是本地缓存。
那本地缓存的计划有哪些呢？且听 Guide 给你来说一说。
一：JDK 自带的 HashMap 和 ConcurrentHashMap 了。
ConcurrentHashMap 能够看作是线程平安版本的 HashMap，两者都是寄存 key/value 模式的键值对。然而，大部分场景来说不会应用这两者当做缓存，因为只提供了缓存的性能，并没有提供其余诸如过期工夫之类的性能。一个略微欠缺一点的缓存框架至多要提供：过期工夫 、 淘汰机制 、 命中率统计 这三点。
二：Ehcache、Guava Cache、Spring Cache 这三者是应用的比拟多的本地缓存框架。
Ehcache的话相比于其余两者更加分量。不过，相比于Guava Cache、Spring Cache来说，Ehcache反对能够嵌入到 hibernate 和 mybatis 作为多级缓存，并且能够将缓存的数据长久化到本地磁盘中、同时也提供了集群计划（比拟鸡肋，可疏忽）。Guava Cache和Spring Cache两者的话比拟像。Guava相比于Spring Cache的话应用的更多一点，它提供了 API 十分不便咱们应用，同时也提供了设置缓存无效工夫等性能。它的外部实现也比拟洁净，很多中央都和ConcurrentHashMap的思维有殊途同归之妙。- 应用
Spring Cache的注解实现缓存的话，代码会看着很洁净和优雅，然而很容易呈现问题比方缓存穿透、内存溢出。
三：后起之秀 Caffeine。
相比于 Guava 来说 Caffeine 在各个方面比方性能要更加优良，个别倡议应用其来代替 Guava。并且，Guava 和 Caffeine 的应用形式很像！
本地缓存诚然好，然而缺点也很显著，比方多个雷同服务之间的本地缓存的数据无奈共享。
4. 为什么要有分布式缓存?/ 为什么不间接用本地缓存?
本地的缓存的劣势非常明显：低依赖 、 轻量 、 简略 、 成本低。
然而，本地缓存存在上面这些缺点：
- 本地缓存对分布式架构反对不敌对，比方同一个雷同的服务部署在多台机器上的时候，各个服务之间的缓存是无奈共享的，因为本地缓存只在以后机器上有。
- 本地缓存容量受服务部署所在的机器限度显著。 如果以后零碎服务所消耗的内存多，那么本地缓存可用的容量就很少。
咱们能够把分布式缓存（Distributed Cache）看作是一种内存数据库的服务，它的最终作用就是提供缓存数据的服务。
如下图所示，就是一个简略的应用分布式缓存的架构图。咱们应用 Nginx 来做负载平衡，部署两个雷同的服务到服务器，两个服务应用同一个数据库和缓存。
应用分布式缓存之后，缓存部署在一台独自的服务器上，即便同一个雷同的服务部署在再多机器上，也是应用的同一份缓存。并且，独自的分布式缓存服务的性能、容量和提供的性能都要更加弱小。
应用分布式缓存的毛病呢，也很不言而喻，那就是你须要为分布式缓存引入额定的服务比方 Redis 或 Memcached，你须要独自保障 Redis 或 Memcached 服务的高可用。
5. 缓存读写模式 / 更新策略
上面介绍到的三种模式各有优劣，不存在最佳模式，依据具体的业务场景抉择适宜本人的缓存读写模式。
5.1. Cache Aside Pattern（旁路缓存模式）
Cache Aside Pattern 是咱们平时应用比拟多的一个缓存读写模式，比拟适宜读申请比拟多的场景。
Cache Aside Pattern 中服务端须要同时维系 DB 和 cache，并且是以 DB 的后果为准。
上面咱们来看一下这个策略模式下的缓存读写步骤。
写：
- 先更新 DB
- 而后间接删除 cache。
简略画了一张图帮忙大家了解写的步骤。
读 :
- 从 cache 中读取数据，读取到就间接返回
- cache 中读取不到的话，就从 DB 中读取数据返回
- 再把数据放到 cache 中。
简略画了一张图帮忙大家了解读的步骤。
你仅仅理解了下面这些内容的话是远远不够的，咱们还要搞懂其中的原理。
比如说面试官很可能会诘问：“在写数据的过程中，能够先删除 cache，后更新 DB 么？”
答案： 那必定是不行的！因为这样可能会造成 数据库（DB）和缓存（Cache）数据不统一 的问题。为什么呢？比如说申请 1 先写数据 A，申请 2 随后读数据 A 的话就很有可能产生数据不一致性的问题。这个过程能够简略形容为：
申请 1 先把 cache 中的 A 数据删除 -> 申请 2 从 DB 中读取数据 -> 申请 1 再把 DB 中的 A 数据更新。
当你这样答复之后，面试官可能会紧接着就诘问：“在写数据的过程中，先更新 DB，后删除 cache 就没有问题了么？”
答案： 实践上来说还是可能会呈现数据不一致性的问题，不过概率十分小，因为缓存的写入速度是比数据库的写入速度快很多！
比方申请 1 先读数据 A，申请 2 随后写数据 A，并且数据 A 不在缓存中的话也有可能产生数据不一致性的问题。这个过程能够简略形容为：
申请 1 从 DB 读数据 A -> 申请 2 写更新数据 A 到数据库并把删除 cache 中的 A 数据 -> 申请 1 将数据 A 写入 cache。
当初咱们再来剖析一下 Cache Aside Pattern 的缺点。
缺点 1：首次申请数据肯定不在 cache 的问题
解决办法：能够将热点数据能够提前放入 cache 中。
缺点 2：写操作比拟频繁的话导致 cache 中的数据会被频繁被删除，这样会影响缓存命中率。
解决办法：
- 数据库和缓存数据强统一场景：更新 DB 的时候同样更新 cache，不过咱们须要加一个锁 / 分布式锁来保障更新 cache 的时候不存在线程平安问题。
- 能够短暂地容许数据库和缓存数据不统一的场景：更新 DB 的时候同样更新 cache，然而给缓存加一个比拟短的过期工夫，这样的话就能够保障即便数据不统一的话影响也比拟小。
5.2. Read/Write Through Pattern（读写穿透）
Read/Write Through Pattern 中服务端把 cache 视为次要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 DB，从而加重了应用程序的职责。
这种缓存读写策略小伙伴们应该也发现了在平时在开发过程中十分少见。抛去性能方面的影响，大概率是因为咱们常常应用的分布式缓存 Redis 并没有提供 cache 将数据写入 DB 的性能。
写（Write Through）：
- 先查 cache，cache 中不存在，间接更新 DB。
- cache 中存在，则先更新 cache，而后 cache 服务本人更新 DB（同步更新 cache 和 DB）。
简略画了一张图帮忙大家了解写的步骤。
读(Read Through)：
- 从 cache 中读取数据，读取到就间接返回。
- 读取不到的话，先从 DB 加载，写入到 cache 后返回响应。
简略画了一张图帮忙大家了解读的步骤。
Read-Through Pattern 理论只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下，产生读申请的时候，如果 cache 中不存在对应的数据，是由客户端本人负责把数据写入 cache，而 Read Through Pattern 则是 cache 服务本人来写入缓存的，这对客户端是通明的。
和 Cache Aside Pattern 一样，Read-Through Pattern 也有首次申请数据肯定不再 cache 的问题，对于热点数据能够提前放入缓存中。
5.3. Write Behind Pattern（异步缓存写入）
Write Behind Pattern 和 Read/Write Through Pattern 很类似，两者都是由 cache 服务来负责 cache 和 DB 的读写。
然而，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不间接更新 DB，而是改为异步批量的形式来更新 DB。
很显著，这种形式对数据一致性带来了更大的挑战，比方 cache 数据可能还没异步更新 DB 的话，cache 服务可能就就挂掉了。
这种策略在咱们平时开发过程中也十分十分少见，然而不代表它的利用场景少，比方音讯队列中音讯的异步写入磁盘、MySQL 的 InnoDB Buffer Pool 机制都用到了这种策略。
Write Behind Pattern 下 DB 的写性能十分高，非常适合一些数据常常变动又对数据一致性要求没那么高的场景，比方浏览量、点赞量。