Redis缓存穿透，缓存击穿，缓存雪崩

缓存穿透

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

解决方案

有很多种方法可以有效地解决缓存穿透问题

• 最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
• 另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案

• redis高可用（事前架构）

  • 这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

• 限流降级（发生中的紧急措施）

  • 这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

• 数据预热（事前预防）

  • 在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

• 给key的过期时间加随机数，防止key在同一时间失效（事前应用）

  • 比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存击穿

是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

• 使用同步锁 synchronized 关键字，修饰在获取缓存的方法里面，保证在多用户同时请求条件下，只有第一个进入的线程去判断是否要查询数据库并存入缓存，其他线程只需在第一个线程结束后，从缓存中读取数据即可，无需再查询数据库。
  上面是对缓存穿透的再次优化，加入线程同步锁 以及 双重检查锁.
  双重检查锁：1.避免当缓存数据没有失效时，其他线程排队等待。
  2.当第一个线程从数据库中获取到数据并存入缓存中时，其他线程直接从缓存获取数据即可。
• 不设置缓存时间，由后台创建定时任务去维护这部分缓存数据。这种方法请求时直接从缓存中获取数据，无需再判断是否从数据库中获取，定时任务也可在请求较少的时间段分批更新缓存数据。
  当然代码量、代码复杂度增大，分批更新代表需要多个定时任务去维护缓存数据，同时更新有可能会造成缓存雪崩的情况。

原文引用

部分内容转载自以下文章
原文链接