缓存穿透，缓存击穿，缓存雪崩

大家好，我是骄阳，今天我们来聊下redis在使用中的注意事项

缓存穿透

缓存穿透是指查询一个根本不存在的数据， redis和数据库都不会命中，而我们 通常出于容错的考虑， 如果从数据库查不到数据则不写入缓存层。

这样就会导致不存在的数据每次请求都打到数据库， 失去了缓存保护数据库的意义。

造成缓存穿透的基本原因有两个：

第一， 自身业务代码写错了，或者数据出现问题。

第二， 一些恶意攻击、 爬虫等造成大量空命中。

缓存穿透问题解决方案：

1、缓存空对象

if (value == null) { cache.expire(key, 60 * 2); }

注意事项：需要设置一个过期时间

2、布隆过滤器

对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。

注意：当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。

布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。

所谓无偏就是能够把元素的 hash 值算得比较均匀。

原理：

向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值，然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 ，就完成了 add 操作。

向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。

如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。

如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。

适用场景

这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景。

优缺点

代码维护较为复杂， 但是缓存空间占用很少。

使用方法

可以用redisson实现布隆过滤器，引入依赖：

<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.6.1</version> </dependency>

注意事项

（1）使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放

（2）布隆过滤器不能删除数据，如果要删除得重新初始化数据。

缓存失效(击穿)

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。

最简单的就是过期时间里加个random随机数

缓存雪崩

缓存雪崩指的是缓存层支撑不住或宕掉后， 流量全部打向后端存储层。

由于缓存层承载着大量请求， 有效地保护了存储层， 但是如果缓存层由于某些原因不能提供服务，于是大量请求都会打到存储层， 存储层的调用量会暴增，由于数据库扛并发的能力没有redis好，所以 造成存储层也会级联宕机的情况。

造成缓存层不可用原因

(1)超大并发过来，缓存层支撑不住，

(2)由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降

预防和解决缓存雪崩问题， 可以从以下三个方面进行着手。

1） 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。

2） 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。

对于服务降级，我们可以针对不同的数据采取不同的处理方式。

当业务应用访问的是非核心数据，例如商品属性，用户信息等时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；

当业务应用访问的是核心数据时，例如商品库存，仍然允许查询缓存，如果缓存缺失，从数据库读取。

3） 做好准备工作。 在项目上线前，测试缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案。

好啦，这就是今天全部的内容，喜欢我的话，可以点个关注支持一下~