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. 缓存雪崩：
产生原因：缓存挂掉
解决方案：快速失败熔断、主从模式、集群模式