认识redis穿透，击穿和雪崩

缓存穿透 ：就是数据不在关系型数据库 ，也没在缓存中，通过程序直接访问Redis数据库

缓存击穿：数据在数据库里，不在缓存中

击穿可能会出现的问题：是指单个key在缓存中查不到，直接去数据库查询，如果数据量大并且在高并发的情况下可能会存在数据库压力过大而荡机（蹦）
注意是高并发的情况下
程序查询时Redis通过同步请求中,先判断检查key保证不存在才去查找数据库查找，有利于提升用户的体验度
最好的解决方式就是单例模式
或者加锁，但是会阻塞其他线程，影响效率

第二种方式设置value不过期
最安全可靠，安全，但是占用空间，内存消耗过大，并且不能保存数据最新，这个需要根据具体业务逻辑来做或者设置一个定时任务

雪崩
雪崩是指多个key查询并且出现高并发，缓存中失效或者查不到，然后都在数据库的查询，从而导致数据库压力突然飙升，从而崩溃

出现的原因：1：key同时失效
2：redis本身崩溃了
方案:

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

可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
不同的key，设置不同的过期时间，具体值可以根据业务决定，让缓存失效的时间点尽量均匀
做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。(这种方式复杂点)
3 击透

一般是出现这种情况是因为恶意频繁查询才会对系统造成很大的问题: key缓存并且数据库不存在，所以每次查询都会查询数据库从而导致数据库崩溃。

解决方案:

1) 使用布隆过滤器: 热点数据等场景(具体看使用场景)

布隆过滤器是什么？

布隆过滤器可以理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。

当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。打个比方，当它说不认识你时，肯定就不认识；当它说见过你时，可能根本就没见过面，不过因为你的脸跟它认识的人中某脸比较相似 (某些熟脸的系数组合)，所以误判以前见过你。

缺点: 1 会存在一定的误判率

2  对新增加的数据无法进行布隆过滤

3 数据的key不会频繁的更改

google 的 gauva 中有布隆过滤的实现

BloomFilter的关键在于hash算法的设定和bit数组的大小确定，通过权衡得到一个错误概率可以接受的结果。

我们设置的容错率越小那么过滤函数也就多，分配的空间也就越大(存放bits)，那么误判率也就越小。

2 将击透的key缓存起来，但是时间不能太长，下次进来是直接返回不存在，但是这种情况无法过滤掉动态的key，就是说每次请求进来都是不同额key，这样还是会造成这个问题

• 点赞
• 收藏
• 分享
• 文章举报