详解Redis缓存穿透/击穿/雪崩原理及其解决方案
目录
- 1.简介
- 2.缓存穿透
- 2.1描述
- 2.2解决方案
- 3.缓存击穿
- 3.1描述
- 3.2解决方案
- 4.缓存雪崩
- 4.1描述
- 4.1解决方案
- 5.布隆过滤器
- 5.1描述
- 5.2数据结构
- 5.3“一定不在集合中”
- 5.4“可能在集合中”
- 5.5”删除困难“
- 5.6为什么不使用HashMap呢？
1. 简介
如图所示，一个正常的请求
1.客户端请求张铁牛的博客。
2.服务首先会请求redis，查看请求的内容是否存在。
3.redis将请求结果返回给服务，如果返回的结果有数据则执行7；如果没有数据则会继续往下执行。
4.服务从数据库中查询请求的数据。
5.数据库将查询的结果返回给服务。
6.如果数据库有返回数据，则将返回的结果添加到redis。
7.将请求到的数据返回给客户端。
2. 缓存穿透
2.1描述
通过接口访问一个缓存和数据库都不存在的数据。
因为服务出于容错考虑，当请求从持久层查不到数据则不写入缓存，这将导致请求这个不存在的数据每次都要到持久层去查询，失去了缓存的意义。
此时，缓存起不到保护后端持久层的意义，就像被穿透了一样。导致数据库存在被打挂的风险。
2.2 解决方案
1.接口请求参数的校验。对请求的接口进行鉴权，数据合法性的校验等；比如查询的userId不能是负值或者包含非法字符等。
2.当数据库返回空值时，将空值缓存到redis，并设置合理的过期时间。
3.布隆过滤器。使用布隆过滤器存储所有可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。
3. 缓存击穿
3.1 描述
某个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，导致数据库存在被打挂的风险。
3.2 解决方案
1.加互斥锁。当热点key过期后，大量的请求涌入时，只有第一个请求能获取锁并阻塞，此时该请求查询数据库，并将查询结果写入redis后释放锁。后续的请求直接走缓存。
2.设置缓存不过期或者后台有线程一直给热点数据续期。
4. 缓存雪崩
4.1 描述
大量的热点数据过期时间相同，导致数据在同一时刻集体失效。造成瞬时数据库请求量大、压力骤增，引起雪崩，导致数据库存在被打挂的风险。
4.1 解决方案
1.将热点数据的过期时间打散。给热点数据设置过期时间时加个随机值。
2.加互斥锁。当热点key过期后，大量的请求涌入时，只有第一个请求能获取锁并阻塞，此时该请求查询数据库，并将查询结果写入redis后释放锁。后续的请求直接走缓存。
3.设置缓存不过期或者后台有线程一直给热点数据续期。
5. 布隆过滤器
5.1 描述
布隆过滤器是防止缓存穿透的方案之一。布隆过滤器主要是解决大规模数据下不需要精确过滤的业务场景，如检查垃圾邮件地址，爬虫URL地址去重， 解决缓存穿透问题等。
布隆过滤器：在一个存在一定数量的集合中过滤一个对应的元素，判断该元素是否一定不在集合中或者可能在集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。
5.2 数据结构
布隆过滤器是基于bitmap和若干个hash算法实现的。如下图所示：
1.元素tie经过hash1，hash2，hash3运算出对应的三个值落到了数组下标为4，6，8的位置上，并将其位置的默认值0，修改成1。
2.元素niu同理落到了数组下标为1，3，4的位置上，并将其位置的默认值0，修改成1。
此时bitmap中已经存储了tie，niu数据元素。
当请求想通过布隆过滤器判断tie元素在程序中是否存在时，通过hash运算结果到数组对应下标位置上发现值已经都被置为1，此时返回true。
5.3 “一定不在集合中”
如图所示：
元素zhang通过布隆过滤器判断时，下标0，2都为0，则直接返回false。
也就是当判断不在bitmap中的元素时，经过hash运算得到的结果在bitmap中只要有一个为0，则该数据一定不存在。
5.4 “可能在集合中”
如图所示：
元素shuaibi通过布隆过滤器判断时，hash运算的结果落到了下标1,3,8上，此时对应下标位置的值都为1，则直接返回true。
这下就尴尬了，因为实际程序中并没有数据shuaibi，但布隆过滤器返回的结果显示有这个元素。这就是布隆过滤器的缺点，存在误判情况。
5.5 ”删除困难“
为什么布隆过滤器删除困难呢，如图所示：
如果删除了“tie”元素，4号位被置为0，则会影响niu元素的判断，因为4号位为0，进行数据校验时返回0，则会认为程序中没有niu元素。
那小伙伴会问，4号位不置为0，行不行？
如果删除了元素，hash碰撞的数组下标不置为0，那么如果继续验证该元素的话，布隆过滤器会继续返回true，但实际上元素已经删除了。
所以布隆过滤器数据删除困难，如果要删除的话，可以参考Counting Bloom Filter。
5.6 为什么不使用HashMap呢？
如果用HashSet或Hashmap存储的话，每一个用户ID都要存成int，占4个字节即32bit。而一个用户在bitmap中只需要1个bit，内存节省了32倍。
并且大数据量会产生大量的hash冲突，结果就是产生hash冲突的数据，仍然会进行遍历挨个比对（即使转成红黑树），这样对内存空间和查询效率的提升，仍然是有限的。
当然：数据量不大时，尽管使用。而且hashmap方便进行CRUD😂
到此这篇关于详解缓存穿透/击穿/雪崩原理及其解决方案的文章就介绍到这了,更多相关缓存穿透/击穿/雪崩内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！
相关推荐
-
Redis中缓存穿透/击穿/雪崩问题和解决方法
目录 缓存问题 1. 缓存穿透---查不到 解决方案 2. 缓存击穿---量太大,缓存过期 解决方案 3. 缓存雪崩 解决方案 缓存问题 1. 缓存穿透---查不到 缓存穿透是指用户想查询一个数据,发现Redis中没有,也就是缓存没有命中,就向持久性数据库发起查询,发现数据库也没有这个数据,于是查询失败了. 当用户请求很多的情况下,缓存没有命中,数据库也没有数据,会给数据库造成很大的压力,这就是缓存穿透. 解决方案 第一种解决方案:使用布隆过滤器 使用布隆过滤器之后,将存储的数据放入布隆过滤器中
-
Redis击穿穿透雪崩产生原因分析及解决思路面试
目录 1.前言 2.问题起因 3.应对击穿的处理思路 4.穿透 5.雪崩 结束 1.前言 大家都知道,计算机的瓶颈之一就是IO,为了解决内存与磁盘速度不匹配的问题,产生了缓存,将一些热点数据放在内存中,随用随取,降低连接到数据库的请求链接,避免数据库挂掉.需要注意的是,无论是击穿还是后面谈到的穿透与雪崩,都是在高并发前提下,比如当缓存中某一个热点key失效. 2.问题起因 有两个主要原因: 1.Key过期: 2.Key被页面置换淘汰. 对于第一个原因是因为在Redis中,Key有过期时间,如果某
-
redis击穿 雪崩 穿透超详细解决方案梳理
Redis击穿 redis缓存击穿是指某一个非常热点的key(即在客户端搜索的比较多的关键字)突然失效了,这时从客户端发送的大量的请求在redis里找不到这个key,就会去数据里找,最终导致数据库压力过大崩掉. 解决方案: 1.将value的时效设置成永不过期 这种方式非常简单粗暴但是安全可靠.但是非常占用空间对内存消耗也是极大.个人并不建议使用该方法,应该根据具体业务逻辑来操作. 2.使用Timetask做一个定时任务 使用Timetask做定时,每隔一段时间对一些热点key进行数据库查询,将
-
详解Redis缓存穿透/击穿/雪崩原理及其解决方案
目录 1.简介 2.缓存穿透 2.1描述 2.2解决方案 3.缓存击穿 3.1描述 3.2解决方案 4.缓存雪崩 4.1描述 4.1解决方案 5.布隆过滤器 5.1描述 5.2数据结构 5.3"一定不在集合中" 5.4"可能在集合中" 5.5"删除困难" 5.6为什么不使用HashMap呢? 1. 简介 如图所示,一个正常的请求 1.客户端请求张铁牛的博客. 2.服务首先会请求redis,查看请求的内容是否存在. 3.redis将请求结果返回给服
-
详解缓存穿透/击穿/雪崩原理及其解决方案
目录 1. 简介 2. 缓存穿透 2.1描述 2.2 解决方案 3. 缓存击穿 3.1 描述 3.2 解决方案 4. 缓存雪崩 4.1 描述 4.1 解决方案 5. 布隆过滤器 5.1 描述 5.2 数据结构 5.3 "一定不在集合中" 5.4 "可能在集合中" 5.5 "删除困难" 5.6 为什么不使用HashMap呢? 1. 简介 如图所示,一个正常的请求 1.客户端请求张铁牛的博客. 2.服务首先会请求redis,查看请求的内容是否存在.
-
详解缓存穿透击穿雪崩解决方案
一:前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 二:缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义.在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞. 三:解决方案 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足
-
详解redis缓存与数据库一致性问题解决
数据库与缓存读写模式策略 写完数据库后是否需要马上更新缓存还是直接删除缓存? (1).如果写数据库的值与更新到缓存值是一样的,不需要经过任何的计算,可以马上更新缓存,但是如果对于那种写数据频繁而读数据少的场景并不合适这种解决方案,因为也许还没有查询就被删除或修改了,这样会浪费时间和资源 (2).如果写数据库的值与更新缓存的值不一致,写入缓存中的数据需要经过几个表的关联计算后得到的结果插入缓存中,那就没有必要马上更新缓存,只有删除缓存即可,等到查询的时候在去把计算后得到的结果插入到缓存中即可. 所
-
Redis缓存穿透/击穿工具类的封装
目录 1. 简单的步骤说明 2. 逻辑缓存数据类型 3. 缓冲工具类的封装 3.1 CacheClient 类的类图结构 3.2 CacheClient 类代码 1. 简单的步骤说明 创建一个逻辑缓存数据类型 封装缓冲穿透和缓冲击穿工具类 2. 逻辑缓存数据类型 这里主要是创建一个可以往Redis里边存放的数据类型 RedisData 的Java类型 import lombok.Data; import java.time.LocalDateTime; @Data public class Re
-
详解Redis 缓存 + Spring 的集成示例
<整合 spring 4(包括mvc.context.orm) + mybatis 3 示例>一文简要介绍了最新版本的 Spring MVC.IOC.MyBatis ORM 三者的整合以及声明式事务处理.现在我们需要把缓存也整合进来,缓存我们选用的是 Redis,本文将在该文示例基础上介绍 Redis 缓存 + Spring 的集成. 1. 依赖包安装 pom.xml 加入: <!-- redis cache related.....start --> <dependency
-
详解Redis 缓存删除机制(源码解析)
删除的范围 过期的 key 在内存满了的情况下,如果继续执行 set 等命令,且所有 key 都没有过期,那么会按照缓存淘汰策略选中的 key 过期删除 redis 中设置了过期时间的 key 会单独存储一份 typedef struct redisDb { dict *dict; // 所有的键值对 dict *expires; //设置了过期时间的键值对 // ... } redisDb; 设置有效期 Redis 中有 4 个命令可以给 key 设置过期时间,分别是 expire pexpi
-
详解高性能缓存Caffeine原理及实战
目录 一.简介 二.Caffeine 原理 2.1.淘汰算法 2.1.1.常见算法 2.1.2.W-TinyLFU 算法 2.2.高性能读写 2.2.1.读缓冲 2.2.2.写缓冲 三.Caffeine 实战 3.1.配置参数 3.2.项目实战 四.总结 一.简介 下面是Caffeine 官方测试报告. 由上面三幅图可见:不管在并发读.并发写还是并发读写的场景下,Caffeine 的性能都大幅领先于其他本地开源缓存组件. 本文先介绍 Caffeine 实现原理,再讲解如何在项目中使用 Caffe
-
详解Redis分布式锁的原理与实现
目录 前言 使用场景 为什么要使用分布式锁 如何使用分布式锁 流程图 分布式锁的状态 分布式锁的特点 分布式锁的实现方式(以redis分布式锁实现为例) 总结 前言 在单体应用中,如果我们对共享数据不进行加锁操作,会出现数据一致性问题,我们的解决办法通常是加锁.在分布式架构中,我们同样会遇到数据共享操作问题,此时,我们就需要分布式锁来解决问题,下面我们一起聊聊使用redis来实现分布式锁. 使用场景 库存超卖 比如 5个笔记本 A 看 准备买3个 B 买2个 C 4个 一下单 3+2+4 =9