创建网站需要哪些要素,遵义企业网站建设,南京网站设计与制作,长沙公众号开发Redis的缓存穿透、缓存雪崩和缓存击穿一. 缓存穿透1.1 概念1.2 造成的问题1.3 解决方案1.4 案例#xff1a;查询商铺信息#xff08;缓存穿透的实现#xff09;二. 缓存雪崩2.1 概念2.2 解决方案三. 缓存击穿#xff08;热点key#xff09;3.1 概念3.2 解决方案3.3 案例查询商铺信息缓存穿透的实现二. 缓存雪崩2.1 概念2.2 解决方案三. 缓存击穿热点key3.1 概念3.2 解决方案3.3 案例查询商铺信息互斥锁和逻辑过期的实现1互斥锁补充SETNXsetIfAbsent2逻辑过期一. 缓存穿透
1.1 概念
缓存模型
定义指客户请求的数据在缓存中和数据库中都不存在这样缓存永远不会命中请求都会发到数据库 (穿透即穿透了缓存和数据库)
1.2 造成的问题
假设不断发送这样的请求则会让数据库崩溃
1.3 解决方案
1主动
增加请求参数的复杂度且有一定规范对请求参数提前做校验加强用户权限校验如用拦截器校验登录状态热点参数的限流
2被动
缓存空对象 为了不再让请求造成缓存穿透则产生一个null空值value””到redis中当下次再请求时就可以从Redis返回而不用去查数据库 优点简单 缺点 ①造成Redis中的内存消耗----- 对这样的null值数据设置TTL有效时间 ②短期不一致Redis中存了null值但是数据库此时真的增加了这条数据而缓存中数据和数据库不一样当有用户来查询时会查到null数据------ 缩短TTL时间 或者手动覆盖数据到Redis中 布隆过滤 【在请求访问Redis之前】添加一个布隆过滤器 布隆过滤器中存储的是byte字节数据存储的是二进制位 数据库中的数据会经过Hash算法将计算后的值存到布隆过滤器当请求发过来时会判断请求的Hash值是否存在于过滤器中若过滤器判断不存在则一定不存在 若过滤器判断存在则只是可能存在不是100%准确所以依然有一定缓存穿透风险的 优点内存占用少只需要存Hash值没有多余key 缺点实现相对复杂可能误判哈希冲突
1.4 案例查询商铺信息缓存穿透的实现
业务逻辑 1.注入stringRedisTemplate的bean从Redis查询商户缓存如果命中则判断是不是空值不是则返回商铺信息是则返回不存在 2.未命中则查询数据库若不存在报错 3.若数据库中存在则用stringRedisTemplate.opsForVlaue将商铺信息更新到Redis中并更新TTL有效时间(兜底) 4.如果数据库中也不存在缓存穿透则将空值写入Redis即value“” 效果 发送id不存在的查询请求查询Redis和数据库缓存穿透了返回“不存在”会在Redis缓存一个空值 假设再发送同样的请求则查询到Redis中的空字符串数据还是返回“不存在”但是不走数据库了
总结1. 缓存穿透则写入空值 2. Redis命中时需要判断是否为空字符串
二. 缓存雪崩
2.1 概念
定义同一时段内有①大量的缓存Key同时失效过期 或者 ②Redis服务宕机导致大量请求发往数据库带来巨大压力
2.2 解决方案
1针对大量缓存同时失效
给不同的key的TTL添加随机值给缓存业务添加降级限流策略牺牲部分服务保护数据库
2针对Redis宕机
启用熔断机制暂停服务用主从节点的方式建立Redis高可用集群哨兵机制 可以实现对服务的监控类比Kafka主从实现数据同步在多个层面建立缓存让Nginx也做缓存Nginx未命中再去Redis再去JVM最后才是数据库 多级缓存在大型电商中如商品详情会使用以应对亿级以上的并发
三. 缓存击穿热点key
3.1 概念
定义 业务通常会有几个数据会被 ①频繁访问比如秒杀活动且 ②缓存重建业务比较复杂这类被频地访问的数据被称为 热点数据。
如果缓存中的某个热点数据过期了且缓存重建耗时较长此时大量的请求线程都会去缓存重建会对数据库带来巨大冲击
3.2 解决方案
1互斥锁 所有请求都去尝试缓存重建所以用互斥锁的方式只让一个请求线程去缓存重建 只有获取到锁的请求线程才能去进行缓存重建而其他请求线程则休眠一会再查询直到锁释放后再访问到新的缓存
优点保持数据的一致性 缺点线程需要等待性能不好牺牲可用性
2逻辑过期
缓存穿透的原因就是因为热点数据过期所以设置一个 逻辑过期 让热点数据在Redis中永不过期不设置TTL 新增一个过期时间的字段放到Value中让线程可以判断是否逻辑过期类似MyBatisPlus的逻辑删除但实际上不是TTL这样每次都能命中线程发现热点数据已经逻辑过期就尝试获取互斥锁 ①如果获取锁成功则再 开启一个新的线程 去缓存重建原线程返回旧数据 ②获取失败则返回旧数据
优点线程不需要等待性能好保证可用性 缺点牺牲一致性
注意 互斥锁方法和逻辑过期都用了互斥锁前者当其他线程发现锁被占用后则会一直重试等待直到缓存重建完成 后者当其他线程发现数据逻辑过期后才去尝试获取锁锁被占用则获取旧的热点数据而不会一直等待
总结互斥锁和逻辑过期都是在解决缓存重建时的并发问题 互斥锁即让请求线程等待保证一致性逻辑过期是可以拿到旧数据即保证了可用性但是牺牲了一致性。
3.3 案例查询商铺信息互斥锁和逻辑过期的实现
1互斥锁
流程 1.注入stringRedisTemplate的bean从Redis查询商户缓存如果命中返回商铺信息 2.如果未命中则尝试获取锁注意锁的key不是商铺id 3.没有拿到锁则休眠一会再重新尝试查询Redis递归 4.获取到锁则缓存重建缓存重建需要去查询数据库查完后更新Redis释放锁 5.返回结果
先建立加锁和解锁两个方法 为了防止锁永不释放给锁加有效期兜底 业务逻辑
测试 使用JMeter模拟多线程并发的场景 设置1000个线程时间共5sQPS200/s
结果 Idea中显示只查询了一次数据库成功
补充SETNXsetIfAbsent
SETNX / setIfAbsentNXnot exist即key不存在时才能set成功 用来作 互斥锁 使用
例 即相当于是互斥锁只有第一个能成功后面的都失败了 释放锁 为了防止锁永远不被释放一般加有效期兜底假设10秒一般业务执行在1秒内
2逻辑过期
