缓存三击-缓存穿透、缓存雪崩、缓存击穿-Toy模板网

这篇具有很好参考价值的文章主要介绍了缓存三击-缓存穿透、缓存雪崩、缓存击穿。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

⭐⭐⭐⭐⭐⭐
Github主页👉https://github.com/A-BigTree
笔记链接👉https://github.com/A-BigTree/Code_Learning
⭐⭐⭐⭐⭐⭐

Spring专栏👉https://blog.csdn.net/weixin_53580595/category_12279588.html

SpringMVC专栏👉https://blog.csdn.net/weixin_53580595/category_12281721.html

Mybatis专栏👉https://blog.csdn.net/weixin_53580595/category_12279566.html

如果可以，麻烦各位看官顺手点个star~😊

如果文章对你有所帮助，可以点赞👍收藏⭐支持一下博主~😆

前言

Redis作为目前使用最广泛的缓存，但在实际开发中会面临缓存异常，分别是缓存雪崩、缓存击穿和缓存穿透，这三种异常会导致大量请求从缓存转移到数据库，如果请求的并发量很大就会导致数据库崩溃。

缓存雪崩

概念

当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。

缓存三击-缓存穿透、缓存雪崩、缓存击穿,Redis缓存,缓存

分析

造成缓存雪崩的关键在于在同一时间大规模的key失效。

出现这个问题有下面几种可能：

第一种可能是Redis宕机；
第二种可能是采用了相同的过期时间；

解决方法

过期时间设置随机值

在原有的失效时间上加上一个随机值，比如，1-5分钟随机。这样就避免了同一时间大量数据过期现象的发生而导致缓存雪崩。

分布式部署且均匀分布热点数据

如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。同时，分布式集群可以防止Redis宕机导致缓存雪崩的问题。

热点数据永不过期

设置热点数据永远不过期。

兜底措施

使用熔断机制。当流量到达一定的阈值时，就直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上。至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果；
服务降级，当大量数据同时失效时，只允许核心数据请求访问数据库；
提高数据库的容灾能力，可以使用分库分表，读写分离的策略；
为了防止Redis宕机导致缓存雪崩的问题，可以搭建Redis集群，提高Redis的容灾性；

举例说明

比如，针对电商项目，一般是采取不同分类商品，缓存不同周期。在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而如果因为缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

缓存击穿

概念

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

分析

关键在于某个热点的key失效了，导致大并发集中打在数据库上。所以要从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。

解决方法

热点的key设置永不过期

从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期；

从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建；

这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

使用互斥锁

大体思路就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了，但性能很不好。

缓存穿透

概念

查询一个数据库一定不存在的数据。使用Redis大部分情况都是通过Key查询对应的值，假如发送的请求传进来的key是不存在Redis中的，那么就查不到缓存，查不到缓存就会去数据库查询。假如有大量这样的请求，这些请求像“穿透”了缓存一样直接打在数据库上，这种现象就叫做缓存穿透。

分析

正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。

解决方法

缓存空对象

如果数据库查询对象为空，就缓存空对象，再次访问这个数据，就会从缓存中获取，以此保护后端数据源。如果缓存NULL，是做无用功，还是会造成缓存穿透。

缓存空对象遇到的两个问题:

如果是网络恶意攻击（每次key不一样，且数据库不存在），缓存占用了更多的内存；

解决方案：

缓存空对象要考虑到缓存时间的设置。这时候设置一个较短的过期时间（通常设定的缓存过期为60秒），就会自动剔除这些键。

如果过期时间设置的过大，数据库在此期间正好添加了该数据，就会出现数据不一致场景；

解决方案：

通过消息系统或者其它方式来清除缓存中的空对象。

使用布隆过滤器

布隆过滤器的作用是某个 key 不存在，那么就一定不存在，它说某个 key 存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一层布隆过滤器，在查询的时候先去布隆过滤器查询 key 是否存在，如果不存在就直接返回。文章来源地址https://www.toymoban.com/news/detail-517159.html