缓存穿透、缓存雪崩、缓存击穿

在应用开发过程中，必然缺少不了缓存的使用，合理的设计和使用缓存不但对系统性能会有指数级的提升，还可以起到保护数据库的作用。
但是使用缓存的过程中也会有一些实战中遇到的问题，就是我们常听到的缓存穿透、缓存雪崩、缓存击穿问题，下面分别从问题产生原因、问题解决方法两方面结合实战案例来分别论述下。

一、缓存穿透

1.1 原因分析

如上图所示，请求首先经过缓存，缓存没有会进行数据库请求，当数据库查询到数据会返回到缓存层进行数据缓存，之后的请求都会被缓存层命中直接返回，起到保护数据库的作用。而有一种特殊情况是如果请求的数据在数据库中也不存在，无法完成缓存层缓存数据，在这种情况下缓存层无法起到保护数据库的作用，而是被请求直接穿透打到数据库上。
那么什么样的请求连数据库都没有数据呢？一般分为恶意请求和真实请求。恶意请求的请求方会故意编写不存在的业务数据进行请求，比如你的接口定义是传入userId获取用户信息，恶意请求故意编写一个00000000或XXXXXXXX这样基本不可能存在的userId来频繁请求接口，类似请求都会导致缓存穿透。还有一种就是真实业务请求，比如当前接口还是通过userId来请求查看当前用户是否是VIP用户，而数据库只存已经成为VIP的用户信息，而现实场景是VIP用户体量可能很小只占10%，其他90%的用户请求都无法进行缓存，大部分请求都穿透了缓存，数据库承受了大量qps。

1.2 解决方案

针对以上缓存穿透产生的原因，一般方案如上图所示的缓存空值，另外就是借助布隆过滤器。
当业务请求查询数据库也没有数据时，不是直接返回，而是和请求到数据一样，对空数据进行缓存，这样在下次请求数据时缓存层数据能够直接返回起到保护数据库的作用，规避了缓存穿透对数据库带来的威胁。
关于布隆过滤器的介绍这里不做概述，大家可以根据它的优点和缺点去分场景应用，这里不做概述。

1.3 方案优化

当缓存空值解决了缓存穿透的问题，同时也带来新的问题，那就是数据不一致。如果缓存空值的数据，在未来的某一时刻有了新的数据，这时候之前缓存的空值对于当前业务场景来说就是脏数据。比如，之前请求userId是Tomcat的用户的确是非VIP用户，我们缓存他的空值结果为非VIP，可能过了一会Tomcat想通了，进行了充值摇身一变成为了VIP用户，这时候业务请求不能再返回之前的空值非VIP用户数据了，否则业务数据就出现不一致造成数据污染也会严重影响该用户在平台的其他业务状态及服务体验。
因此，需要在业务逻辑变更时进行缓存刷新操作，一般可以删除历史缓存将新业务数据同步写入到缓存中起到数据更新的目的，保证数据一致性。

二、缓存雪崩

2.1 原因分析

缓存雪崩这个词顾名思义，非常形象，就是缓存数据集体瞬间像雪崩一样失效，这时缓存层就如同坍塌，保护数据库的这层屏障消失了。

2.2 解决方案

避免缓存雪崩产生的方法就是避免设置同一时间所有缓存失效，通常做法是将缓存时间设置成不同阈值，让缓存不会在同一时刻同时失效。

三、缓存击穿

3.1 原因分析

这里说的缓存击穿，其实和缓存穿透的含义差不多，都是因为请求绕过了缓存直接打到数据库，但是形成原因不同。可以看上图，做数据缓存时，请求到数据库数据后会将数据缓存，当缓存未有数据更新时大批量请求同时抵达，这时即使做了缓存逻辑，但是由于从数据库拿到数据更新到缓存需要时间，在这个间隙期间产生了缓存击穿现象。

3.2 解决方案

避免上述所说的缓存击穿，可以在数据库返回结果到缓存数据更新这个间隙期间增加分布式锁来解决，当缓存数据更新完成释放分布式锁，在加锁期间所有请求直接返回起到保护数据库的作用，这里特别注意的是对分布式锁要设置合理地过期时间，比如可能这个业务请求在1s内可以完成，那么可以设置5s，在较长的时间内确保可以完成缓存更新操作即可，完成后主动移除分布式锁，所有的分布式锁都要设置合理的过期时间避免产生“死锁”使业务逻辑产生问题。

除了分布式锁来控制防止缓存穿透问题的出现，还可以如上图，在查询缓存没有时直接将缓存更新成空值，确保其他线程请求后直接返回空值起到保护数据库的作用，之后当前线程查询到数据库数据直接返回更新缓存成真实数据，如果没查到也不进行缓存更新了。