Redis——缓存预热+缓存雪崩+缓存击穿+缓存穿透
文章目录
- 1、 缓存预热
- 2、 缓存雪崩
- 3、 缓存击穿
- 4、 缓存穿透
- 总结
1、 缓存预热
什么是预热:
mysql加入新增100条记录,一般默认以mysql为准作为底单数据,如何同步给redis(布隆过滤器)这100条新数据。
为什么需要预热:
mysql有100条新纪录,redis无
- 什么都不做,只对mysql做了数据新增,利用redis的会写机制,让它逐步实现100条新增记录的同步。最好是提前晚上部署发布版本的时候,由自己人提前做一次,让redis同步了,不要把这个问题留给客户。
- 通过中间件或者程序自行完成。
2、 缓存雪崩
发生缓存雪崩后的影响:
- redis主机挂了,redis全盘崩溃,偏硬件运维。
- redis中有大量key同时过期,大面积失效,偏软件开发。
预防+解决:
- redis中key设置为永不过期或者过期时间错开
- redis缓存集群实现高可用(主从 + 哨兵、Redis Cluster、开启Redis持久化机制aof/rdb,尽快回复缓存集群)
- 多缓存结合预防雪崩(ehcache本地缓存 + redis缓存)
- 服务降级 (Hystrix或者阿里sentinel限流或降级)
- 阿里云-云数据库Redis版
3、 缓存击穿
是什么:
大量的请求同时查询一个key时,此时这个key正好失效了,就会导致大量的请求都打到数据库上面去。简单说就是热点key突然失效了,暴打mysql。
危害:
会造成某一时刻数据库请求量过大,压力剧增。
一般技术部门需要知道热点key时哪些个?做到心里有数防止击穿。
解决:
缓存击穿——热点key失效——胡吃更新、随机退避、差异失效时间
热点key失效的原因:(1)时间到了自然清楚但还被访问到(2)delete掉的key,刚巧又被访问。
方案1:差异失效时间,对于访问频繁的热点key,干脆就不设置过期的时间。
方案2:互斥更新,采用双检加锁策略。
4、 缓存穿透
原理:
请求去查询一条记录,先查redis中没有,后查mysql中也没有,即都查询不到该条记录,但是请求每次都会打到数据库上面去,导致后台数据库压力暴增,这种现象称为缓存穿透,这个让redis变成了一个摆设。
解决方式:
-
空对象缓存:空对象缓存或缺省值。
第一种解决方案: 回写增强
如果发生了缓存穿透,可以针对要查询的数据,在Redis里存一个和业务部门商量后确定的缺省值(比如零、负数、defaultNull等)。比如键uid:abcxxx,值defaultNull作为案例的key和value。先去redis查键uid:abcdxxx没有,再去mysql查没有获得,这就发生了一次穿透现象。
可以增强回写机制。
mysql也查不到的话也让redis存入刚刚查不到的key并保护mysql。
第一次查来查询uid:abcxxx,redis和mysql都没有,返回null给调用者,但是增强回写后第二次来查uid:abcxxx,此时redis就有值了。可以直接从Redis中读取default缺省值返回给业务应用程序,避免了把大量请求发送给mysql处理,打爆mysql。
但是此种方法挡不住黑客的恶意攻击,有缺陷。只能解决key相同的问题。 -
布隆过滤器
总结
1. 缓存更新方式
产生原因:数据变更、缓存时效性
解决方案:同步更新、失效更新、异步更新、定时更新
2. 缓存不一致
产生原因:同步更新失败、异步更新
解决方案:增加重试、补偿任务最终一致
3. 缓存穿透:
产生原因:恶意攻击
解决方案:空对象缓存、布隆过滤器
4. 缓存击穿:
产生原因:热点key失效
解决方案:互斥更新、随机退避、差异失效时间
5. 缓存雪崩:
产生原因:缓存挂掉
解决方案:快速失败熔断、主从模式、集群模式