缓存的穿透、雪崩、击穿

👏作者简介：大家好，我是笙一X，java大二练习生，喜欢算法和Java相关知识。

📕正进行的系列：算法 、JUC从入门到成神、Spring、运维、分布式、数据库

目录​​​​​​​

前言

缓存穿透

解决方案

缓存雪崩

解决方案

缓存击穿

解决方案

总结

---

前言

        使用Redis做缓存想必大家并不陌生，但此外，我们有必要对一些业务问题的处理方法进行了解。本文我们简单来学习缓存穿透、雪崩和击穿的业务背景、解决方案。

缓存穿透

        在业务中我们会遇到客户端请求查询缓存和数据库中都不存在的数据，这样的请求一定会打入数据库中。由于数据库中不存在数据，所以无论如何缓存也不可能建立。假设这样的请求有很多很多，数据库非常容易因为压力过大而挂掉。

解决方案

有两种解决方案：

方案1：缓存无效值

        在未命中数据库中数据时，同样将这样的 key 缓存起来，在缓存时设置TTL，这样可以短时间内避免多次查询时反复查询数据库，避免大量相同请求瞬间打到数据库上，减轻压力。当然，也需要去调查为什么会有如此的数据请求，如果是恶意攻击我们可以选择在网关处对 ip 进行限制。

方案2：布隆过滤器

        布隆过滤器的详细讲解我在这里不做赘述，感兴趣的同学可以自行查阅相关资料。

        我们需要了解到布隆过滤器的作用：

                1.以小内存标记大量数据

                2.当布隆过滤器认为元素不存在时，它肯定不存在

                3.当布隆过滤器认为元素存在时，它可能存在。

        可以把所有合法的 key 利用布隆过滤器标记出来，当用户发出请求时，先基于布隆过滤器判断。如果不存在则直接拒绝请求，存在则去查询缓存。尽管布隆过滤存在误差，但一般很少出现，可以大大减少数据库压力。

方案3：参数校验（我认为是所有业务的前提）

        对于不合理的请求参数我们要做好检验，参数校验是很重要的。不要想着遇到问题再去解决，再去追究责任。“后端不要相信上游传来的任何数据！！！”

        做好参数校验，我们可以从问题的源头遏制，不让问题能发出。

缓存雪崩

        缓存内如果出现大量数据同时失效的情况，此时如果有大量请求查询这些数据，全部压力都会给到数据库，造成宕机。

解决方案

方案1：设置随机TTL

        方法简单粗暴，但是非常管用。既然为了让大量 key 不会同时过期，那就设置为随机过期时间好了。

方案2：不设置过期时间

        不过期的话，正常业务请求自然就不会打到数据库了。因为对于一些热点数据，我们可以一直让它存在缓存里，在活动结束后手动删除。

方案3：互斥锁

        对业务加锁，比如某个key只允许一个线程查询数据和写缓存。但这种方式会阻塞其他的线程，导致吞吐量下降，很多高并发场景下并不适用。

方案4：熔断机制，进行限流

        同样是防止过多的请求打在数据库上将数据库击垮，但可能存在用户需要刷新多次才能使用的情况。

缓存击穿

        热点 key 过期或删除后，大量请求在瞬间袭来。在缓存还未建立的过程中，大量请求打入数据库，造成数据库挂掉。

解决方案

方案1：逻辑过期

        大多数时候，我们的热点 key 要保持不过期或者严格规范过期时间，避免出现击穿状况。通常使用逻辑过期，把过期时间存在 key 对应的value里，如果发现要过期了，把缓存建立的过程执行在一个新的异步线程中。在建立完成前，对于用户的请求先返回已经过期的数据，建立完成后存入缓存再返回给用户新数据。

方案2：互斥锁

        与上述同理，不做赘述。

总结

        不难发现，对于缓存的三个问题，我们的解决方案有共通的地方。这恰巧证明了，解决方案只是思路，我们要根据实际业务来选择和规划我们自己的解决方案。不要无脑认为这个问题就是这样解决的... ...

        我是笙一，Java 大二练习生，如果这篇文章对你有帮助的话，不妨给个赞吧！感谢支持！