共计 2396 个字符，预计需要花费 6 分钟才能阅读完成。
举荐????：靠近 100K star 的 Java 学习 / 面试指南：JavaGuide
看到很多小伙伴简历上写了“纯熟应用缓存 ”，然而被我问到“ 缓存罕用的 3 种读写策略”的时候却一脸懵逼。
在我看来，造成这个问题的起因是咱们在学习 Redis 的时候，可能只是简略了写一些 Demo，并没有去关注缓存的读写策略，或者说压根不晓得这回事。
然而，搞懂 3 种常见的缓存读写策略对于理论工作中应用缓存以及面试中被问到缓存都是十分有帮忙的！
上面我会简略介绍一下本人对于这 3 种缓存读写策略的了解。
另外，这 3 种缓存读写策略各有优劣，不存在最佳，须要咱们依据具体的业务场景抉择更适宜的。
集体能力无限。如果文章有任何须要补充 / 欠缺 / 批改的中央，欢送在评论区指出，共同进步！——爱你们的 Guide 哥
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，然而给缓存加一个比拟短的过期工夫，这样的话就能够保障即便数据不统一的话影响也比拟小。
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 的问题，对于热点数据能够提前放入缓存中。
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 的写性能十分高，非常适合一些数据常常变动又对数据一致性要求没那么高的场景，比方浏览量、点赞量。
我的 Github 地址：Snailclimb – Overview
