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

数据库作为系统的数据存储模块，承接了系统很重要的存储功能，如果请求量过大，有可能将数据库打爆，导致整个系统的服务都不可用，为了避免这种情况的发生，我们通常会通过在DB的查询之前架设一个缓存来为DB缓解压力，下面，就简单描述下缓存层可能出现的几类问题。

一、缓存穿透

名词解释

缓存穿透指的是查询一个根本不存在的数据，由于缓存和DB都不会命中数据，所以请求都会打到DB，从而压垮数据库。比如使用一个不存在的主键查询用户信息。

解决方案

1、缓存空结果

如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存。这个方案有很大的弊端，就是要求对数据时效性不高的场景可以考虑。当然，就算对时效性要求不高，对空结果的过期时间也要设计的很短，最好不超过五分钟，可根据不同场景自己定义。

2、设置白名单：

使用bitmaps类型（位操作）定义一个可以访问的名单，名单里是对所有可能查询到的参数。名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

3、使用过滤器：

使用一个过滤器的方案提前过滤掉无效数据或一部分无效数据。比如市面上常见的布隆过滤器和布谷鸟过滤器。
布隆过滤器就是通过对一个key的三次哈希结果进行存储，下一个key的三次哈希结果如果与现有存储的数据有一次没有哈希冲突，代表这个数据一定无效。但反之如果三次结果均哈希冲突的话，不一定代表了数据有效。所以布隆过滤器只能过滤掉一部分无效数据，无法进行精准排除。

二、缓存击穿

名词解释

缓存击穿指的是缓存中没有但数据库中有的数据，由于一些原因（比如缓存时间到期），这时候由于并发量特别大，读缓存没读到数据，大量的请求就在一瞬间打进数据库，瞬间给数据库造成过大的压力。

解决方案

1、缓存预热：

在预测到Redis高峰访问前，提前把一些热门数据存入Redis中，并根据需求加大对这些热key的时长调整，现场监控哪些数据是热门数据，实时调整该热key的过期时长。
弊端： 对业务预测能力要求较高，而且需要派专人专岗进行热门数据更新。

2、加锁：

就是在缓存失效的时候，不是立即去查DB，而是先进行加锁操作，保证读DB的请求只有一个。
弊端： 缓存失效的瞬间会有大量请求排队等待，影响性能，会造成线程阻塞。

三、缓存雪崩

名词解释

缓存雪崩是指缓存同一时间大面积的失效，会导致后续的请求都会打到数据库上，造成数据库短时间内承受大量请求而崩掉。
而造成这个情况的主要原因一般为：
1、某个Redis服务挂了重启。
2、对缓存数据设置了相同的过期时间，导致某时间段内大量缓存集中失效。

解决方案

1、构建多级缓存架构：

以空间换时间，设计多级缓存架构，领缓存时间不是那么容易被控制。比如：nginx缓存+redis缓存+其他缓存（ehcache等）

2、使用锁或队列：

在读库的时候想办法让它排队，比如使用加锁或者队列的形式。让读库的时候只有一个线程在跑。
弊端： 读库时候会有大量请求排队等待，影响性能，会造成线程阻塞。不适用高并发情况。

3、自动更新：

记录缓存数据是否过期，如果过期会就开启另外的线程在后台去重新拉取缓存存起来。

4、合理设置失效时间：

在设置缓存过期时间时，在原有时间后加上一个随机值，避免缓存在同一时间过期。
示例： 比如缓存原本设计一个小时时间，在存储过程中随机取一个5分钟以内的时间数值加在原本的时间上。