缓存三击-缓存穿透、缓存雪崩、缓存击穿
⭐⭐⭐⭐⭐⭐
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~😊
如果文章对你有所帮助,可以点赞👍收藏⭐支持一下博主~😆
文章目录
- 缓存三击-缓存穿透、缓存雪崩、缓存击穿
- 前言
- 缓存雪崩
- 概念
- 分析
- 解决方法
- 过期时间设置随机值
- 分布式部署且均匀分布热点数据
- 热点数据永不过期
- 兜底措施
- 举例说明
- 缓存击穿
- 概念
- 分析
- 解决方法
- 热点的key设置永不过期
- 使用互斥锁
- 缓存穿透
- 概念
- 分析
- 解决方法
- 缓存空对象
- 使用布隆过滤器
前言
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 是否存在,如果不存在就直接返回。
- 布隆缓存器详细介绍👉缓存穿透-布隆缓存器