阿里妹导读：响应时间长，遇到性能瓶颈时，开发者第一个想到的总是性能优化。《什么技能产品经理不会提，但技术人必须懂？》讲到了什么时候需要使用缓存。但缓存的用法是什么？一旦缓存使用不当，或稍有不注意，反而会翻车，导致系统投入更多的维护成本，陡增更高的复杂度。今天，科怀就来讲讲缓存的正确使用姿势。

1. 常见概念

在合理应用缓存前，需要了解缓存领域里相关的几个常用术语：

1）缓存命中：表示数据能够从缓存中获取，不需要回源；
2）Cache miss：表示没有命中缓存，如果缓存内存中还有内存空间的话，会将数据加入到缓存中；
3）存储成本：当没有命中缓存时，回源获取后会将数据放置到存储中，整个将数据放置到存储空间所需要的时间以及空间称之为存储成本；
4）缓存失效：当源数据发生变更后，意味着缓存中的数据失效；
5）缓存污染：将不经常访问的数据放置到缓存存储空间中，以至于高频访问的数据无法放置到缓存中；
6）替代策略：当数据放置到缓存空间时，由于空间不足时，就需要从缓存空间中去除已有的数据，选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些：

• Least-Recently-Used（LRU）
• Least-Frequently-Used（LFU）
• SIZE
• First in First Out（FIFO）

由于存储空间有限，替代策略要解决的核心问题是尽量保留高频访问的缓存数据，降低缓存污染以提升缓存命中率和整体的缓存效率，难点在于，需要基于数据历史访问情况，以一种合适的对未来访问情况的预估才能找到更佳的策略。

2. 访问缓存场景分析

使用缓存通常的操作是，请求先访问缓存数据，如果缓存中不存在的话，就会回源到数据库中然后将数据写入到缓存中；如果存在的话就直接返回数据。从整个过程来看，缓存层就处于数据访问的前置环节，分担数据库在高并发容易出现系统故障的风险，所以在使用过程中需要对缓存层很谨慎的进行分析。在访问缓存数据时，有常见的三大场景：缓存穿透、缓存击穿以及缓存雪崩。

2.1 缓存穿透

现象：每次请求直接穿透缓存层，直接回源到数据库中，给数据库带来了巨大访问压力，甚至宕机。

原因：访问数据会先访问缓存，如果数据不存在缓存中才会查询数据库，但是如果查询数据库也查询不出来数据，也是说当前访问数据永远不会写入缓存中。这样就导致了，访问一定不存在的数据，就相当于缓存层形同虚设，每次请求都会到db层，造成数据库负担过大。

解决方案：

• 方案一：采用bloom filter保存缓存过的key，在访问请求到来时可以过滤掉不存在的key，防止这些请求到db层；
• 方案二：如果db查询不到数据，保存空对象到缓存层，设置较短的失效时间；
• 方案三：针对业务场景对请求的参数进行有效性校验，防止非法请求击垮db。

2.2 缓存击穿

现象：当某一key失效时，造成大量请求到db层，击垮存储层。

原因：为了保证缓存数据的时效性，通常会设置一个失效时间，如果是热点key，高并发时会有海量请求直接越过缓存层到数据库，这样就会给数据库造成的负担增大，设置宕机。

解决方案

• 方案一：使用互斥锁，当缓存数据失效时，保证一个请求能够访问到数据库，并更新缓存，其他线程等待并重试；
• 方案二：缓存数据“永远不过期”，如果缓存数据不设置失效时间的话，就不会存在热点key过期造成了大量请求到数据库。但是，缓存数据就变成“静态数据”，因此当缓存数据快要过期时，采用异步线程的方式提前进行更新缓存数据。

2.3 缓存雪崩

现象：多个key失效，造成大量请求到db层，导致db层负担过重甚至宕机。

原因：缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。

解决方案：

• 方案一：使用互斥锁的方式，保证只有单个线程进行请求能够达到db；
• 方案二：多每个key的失效时间在基础时间上再加上一个1~5分钟的随机值，这样就能保证大规模key集体失效的概率，并且需要尽量让多个key的失效时间能够均匀分布；

2.4 总结

缓存穿透、缓存击穿以及缓存雪崩这三个术语很容易弄混，也是读缓存中典型的三个场景问题，做一下简单的总结是很有必要的。缓存穿透强调是获取本不存在的缓存数据，请求必然会越过缓存层直接到达到存储层，很明显这是利用业务规则的漏洞对系统发起攻击，解决方案的核心原则是过滤这些非法业务请求，与是否是热点数据、缓存失效时间等因素没有关系。

缓存击穿强调的是热点key的失效，导致某一时刻大量请求会直接到db层，解决方案的核心原则是规避数据库的并发操作。缓存雪崩强调的多个key的集体失效，与key是否是热点数据并不是必然的因素，解决方案的核心原则则让key之间的失效时间分布更加均匀，避免集体失效的情况。

3. 数据更新场景分析

引入缓存后数据会分别存放到缓存以及数据库两个地方，因此数据更新时，需要涉及到这两处地方得更新，并且更新时序的不同会有不同的结果。关于数据更新目前业界已经沉淀了Cache Aside Pattern，Read/Write through等多种方式。

3.1 Cache Aside Pattern

这是很通用的更新策略，主要流程如下：

图片来源：https://coolshell.cn/articles/17416.html

主要涉及到如下几点：

• 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
• 命中：应用程序从cache中取数据，取到后返回。
• 更新：先把数据存到数据库中，成功后，再让缓存失效。

Cache Aside Pattern在数据更新的时候是采用先更新数据库，再失效缓存。为什么需要采用这样的方式来解决数据更新的问题，先假设更新数据库以及缓存都会事务成功，由于某一种更新导致的不一致性在下一章节进行讨论。

1）为什么不是更新缓存，而是失效（删除）缓存？

❶ 并发写容易写覆盖造成脏数据问题：当数据发生更新的时候，针对缓存数据可以有两种方式来进行处理分别是更新缓存数据以及失效数据让下一次读请求重新从db中获取数据后重载入缓存中。假设更新缓存数据的话，在并发情况下会存在多线程写缓存造成脏数据的问题，如下图：