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

一、缓存处理流程

前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果。

二、缓存穿透

描述:

缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。

解决方案:

1. 接口层增加校验 , 或缓存空对象. 将 null 变成一个值.

  也可以采用一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

缓存空对象会有两个问题:

  第一,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间 ( 如果是攻击,问题更严重 ),比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。

  第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为 5分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2. 使用布隆过滤

  对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃。还有最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。

可参考: https://www.cnblogs.com/CodeBear/p/10911177.html

三、缓存击穿

描述:

缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力

解决方案:

设置热点数据永远不过期。
加互斥锁,互斥锁参考代码如下:
         

说明:

1)缓存中有数据,直接走上述代码13行后就返回结果了

2)缓存中没有数据,第1个进入的线程,获取锁并从数据库去取数据,没释放锁之前,其他并行进入的线程会等待100ms,再重新去缓存取数据。这样就防止都去数据库重复取数据,重复往缓存中更新数据情况出现。

3)当然这是简化处理,理论上如果能根据key值加锁就更好了,就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据,上面代码明显做不到这点。

四、缓存雪崩

描述:

缓存雪崩是指缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至down机。和缓存击穿不同的是,缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

解决方案:

  1. 缓存数据的过期时间设置随机,防止同一时间大量数据过期现象发生。

  2. 加锁排队. 限流-- 限流算法. 1.计数 2.滑动窗口 3.  令牌桶Token Bucket 4.漏桶 leaky bucket

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

业界比较常用的做法,是使用mutex。简单地来说,就是在缓存失效的时候(判断拿出来的值为空),不是立即去load db,而是先使用缓存工具的某些带成功操作返回值的操作(比如Redis的SETNX或者Memcache的ADD)去set一个mutex key,当操作返回成功时,再进行load db的操作并回设缓存;否则,就重试整个get缓存的方法。

SETNX,是「SET if Not eXists」的缩写,也就是只有不存在的时候才设置,可以利用它来实现锁的效果。

  3.数据预热

可以通过缓存reload机制,预先去更新缓存,再即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀

  4.做二级缓存,或者双缓存策略。即分布式部署缓存数据库,将热点数据均匀分布在不同搞得缓存数据库中。

A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期。

4.缓存永远不过期    设置热点数据永远不过期。

这里的“永远不过期”包含两层意思:

(1) 从缓存上看,确实没有设置过期时间,这就保证了,不会出现热点key过期问题,也就是“物理”不过期。

(2) 从功能上看,如果不过期,那不就成静态的了吗?所以我们把过期时间存在key对应的value里,如果发现要过期了,通过一个后台的异步线程进行缓存的构建,也就是“逻辑”过期.

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

参考:https://blog.csdn.net/kongtiao5/article/details/82771694

   https://blog.csdn.net/lby0307/article/details/79680326

原文地址:https://www.cnblogs.com/xia-yi/p/11778744.html

时间: 2024-10-22 13:35:23

Redis_缓存穿透、缓存击穿、缓存雪崩的相关文章

缓存穿透、击穿、雪崩区别和解决方案

转自公众号:自强学堂 文中的cache指缓存,比如redis,db指数据库,比如mysql. 一.缓存的三种模式 这里主要指的是应用代码对 cache 和 db 中数据的维护方式. 1.1 应用代码同时更新 cache 和 db a)数据写入流程 b)数据读取流程 1.2 应用代码只更新 cache,cache 负责同步更新 db 此时可以将 cache 和 db 看成一个整体,db 自己维护 cache. 1.3 应用方代码更新缓存,另外将 cache 中数据定期更新到 db 类似于 Linu

缓存雪崩 Cache Avalanche 缓存穿透 Cache Penetration 缓存击穿 Hotspot Invalid

一.无处不在的缓存缓存在计算机系统是无处不在,在CPU层面有L1-L3的Cache,在Linux中有TLB加速虚拟地址和物理地址的转换,在应用层有Redis等内存数据库缓存.在浏览器有本地缓存.手机有本地文件缓存等等.可见,缓存在计算机系统中有非常重要的地位,主要作用就是提高响应速度.减少磁盘读取等,本文主要讨论在高并发系统中的缓存系统.一句话概括缓存系统在高并发系统中的地位的话,就是: 如果高并发系统是烤羊肉串,那么缓存系统就是那一撮孜然...... 二.高并发系统中的缓存 缓存系统的作用 缓

缓存穿透、并发和雪崩那些事

0 题记 缓存穿透.缓存并发和缓存雪崩是常见的由于并发量大而导致的缓存问题,本文讲解其产生原因和解决方案. 缓存穿透通常是由恶意×××或者无意造成的:缓存并发是由设计不足造成的:缓存雪崩是由缓存同时失效造成的,三种问题都比较典型,也是难以防范和解决的.本节给出通用的解决方案,以供在缓存设计的过程中参考和使用. 1 缓存穿透 缓存穿透指的是使用不存在的key进行大量的高并发查询,这导致缓存无法命中,每次请求都要穿透到后端数据库系统进行查询,使数据库压力过大,甚至使数据库服务被压死. 我们通常将空值

缓存穿透、缓存击穿、缓存雪崩及其解决方案

1.缓存穿透 缓存穿透是指查询一个一定不存在的数据,因为缓存中也无该数据的信息,则会直接去数据库层进行查询,从系统层面来看像是穿透了缓存层直接达到DB,从而称为缓存穿透,没有了缓存层的保护,这种查询一定不存在的数据对系统来说可能是一种危险,如果有人恶意用这种一定不存在的数据来频繁请求系统(准确的说是攻击系统),请求都会到达数据库层导致DB瘫痪从而引起系统故障. 解决方案 缓存穿透业内的解决方案已经比较成熟,主要常用的有以下几种: bloom filter:类似于哈希表的一种算法,用所有可能的查询

缓存穿透、缓存击穿、缓存雪崩区别和解决方案

一.缓存处理流程 前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果. 二.缓存穿透 描述: 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大. 解决方案: 接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截: 从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-va

缓存穿透,缓存击穿,缓存雪崩

本文链接:https://blog.csdn.net/kongtiao5/article/details/82771694 一.缓存处理流程 前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果. 二.缓存穿透 描述: 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大. 解决方案: 接口层增加校验

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

1.缓存雪崩 通常我们在数据量请求大或者热点数据都会做缓存,通常情况缓存的数据是通过定时任务刷新,或者查询不到后,通过数据库查询后更新的,定时任务刷新的场景就会有问题,因为所有的key会在同一时间失效,那么在秒杀的场景中,如果缓存失效,大量的请求全部落入数据库,数据库必然是扛不住的,可能还没收到报警,实际上数据库已经宕机了 应对这种场景的处理方法是:1)在批量往redis中存数据的时候,把每个key的失效时间都加一个随机值,这样可以保证不会在同一时间大面积失效.2)电商应用目前使用redis都是

阿里面试Redis最常见的三个问题:缓存击穿、雪崩、穿透(带答案)

点赞再看,养成习惯,微信搜索[三太子敖丙]我所有文章都在这里,本文 GitHub https://github.com/JavaFamily 已收录,有一线大厂面试完整考点,文末有福利. 正文 上一期吊打系列我们提到了Redis的基础知识,还没看的小伙伴可以回顾一下 <吊打面试官>系列-Redis基础 那提到Redis我相信各位在面试,或者实际开发过程中对缓存雪崩,穿透,击穿也不陌生吧,就算没遇到过但是你肯定听过,那三者到底有什么区别,我们又应该怎么去防止这样的情况发生呢,我们有请下一位受害者

缓存穿透与缓存雪崩

缓存穿透 什么是缓存穿透? 一般的缓存系统,都是按照key去缓存查询,如果不存在对应的value,就应该去后端系统查找(比如DB).如果key对应的value是一定不存在的,并且对该key并发请求量很大,就会对后端系统造成很大的压力.这就叫做缓存穿透. 如何避免? 1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该key对应的数据insert了之后清理缓存. 2:对一定不存在的key进行过滤.可以把所有的可能存在的key放到一个大的Bitmap中,查询时通过该bitmap过滤.[感觉