Redis 缓存穿透、缓存击穿、缓存雪崩

缓存穿透

问题描述：
  key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
解决办法：
  一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
  有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
  另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存击穿

问题描述：
  key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决办法：

1、设置热点key永不过期

2、加锁，根据热点key从缓存中获取到的value为空时，先锁上，再去查DB将数据加载到缓存，若其它线程获取锁失败，则等待一段时间后重试，从而避免了大量请求直接打到DB。单机可以使用synchronized或ReentrantLock，分布式需要加分布式锁，如Redis分布式锁。【为了不阻塞对其他key的请求，此处可以用热点key来加锁】

缓存雪崩

问题描述：
  当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
解决办法：

1、保证缓存层服务高可用性，如使用Redis Sentinel 和 Redis Cluster，双机房部署，保证Redis服务高可用。

2、通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。

布隆过滤器

  我们想这样一个问题，如果想判断某个元素是不是在一个集合里，一般做法是将集合中所有的元素保存起来，然后通过比较确定，比如HashMap。但是随着集合中元素的增加，数据量超大时，我们需要的存储空间也越来越大，甚至超过服务器内存，这时我们就不能再用HashMap等数据结构了。
这时布隆过滤器就出场了，它的空间效率非常好，它是一个二进制向量，每一位存放的是0或1，初始时默认为0，长下面这样：

当一个元素加入集合时，通过 K 个 Hash 函数将这个元素映射成 k 个值 ：K1、K2、K3…，把向量中下标为K1、K2、K3…的位置置为1 。

比如，元素X进来，将X作为参数，通过3个hash函数的计算，分别得到3个值：Hash1(X)=5；Hash2(X)=2；Hash3(X)=9；那么我们就将布隆过滤器中下标为5、2、9的位置分别置为1，如下，

可以看出，布隆过滤器根本没有存放完整的数据，只是运用一系列随机映射函数计算出位置，然后填充二进制向量，所以它的空间效率非常好。
※ 有一个元素Y，怎么判断Y在布隆过滤器中是否存在呢？

同样将Y作为参数，通过3个hash函数的计算，分别得到3个值，比如是：4/6/8，我们只要看下标为4/6/8的位置是不是都是1，

如果都是1，则元素Y可能存在于集合中，为什么说可能呢——hash碰撞，不同的两个元素，经过同样的hash函数，计算出来的值，从概率上来讲是有可能重复的。所以这也是布隆过滤器最大的缺点，存在误判率。

如果不全是1，则元素Y肯定不存在。

即：当它说某个 key 不存在时，key一定不存在；当它说某个 key 存在时，key 可能存在。

※ 布隆过滤器是怎样解决缓存穿透的？

预先将所有缓存数据的key存放到布隆过滤器中，当一个查询请求过来的时候，先判断这个key在布隆过滤器中是否存在？

如果不存在，直接返回提示，都不用去查缓存更不用说DB了；

如果存在，则去查缓存，但我们知道布隆过滤器判断存在有一定的误判率，这里我是这样理解的，如果这个误判率针对你们的业务场景是可被接受的则可以忽略，另外我们在用Guava实现布隆过滤器的时候可以指定误判率不超过多少，你可以指定一个可被你接受的值。再或者，因为布隆过滤器可以过滤掉绝大多数的恶意key，针对少部分的漏网之鱼，我们可以在缓存层面使用功能上面说过的缓存空值或加锁的方案。

注意：布隆过滤器虽然能很好的解决问题，但是它的缺点也很明显。
那就是当数据量达到上限后，bitmap每一个位上全部都是1时，此时不管什么key都判定为存在。