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

概述：

1. 缓存穿透：大量请求根本不存在的key， 应用服务器压力变大
2. 缓存雪崩：redis中大量key集体过期，数据库压力变大，服务器崩溃
3. 缓存击穿：redis中一个热点key过期（大量用户访问该热点key，但是热点key过期），，数据库的访问压力瞬间激增

三者出现三者出现的根本原因：Redis命中率下降，请求直接打在DB上。

        正常情况下，大量的资源请求都会被redis响应，在redis得不到响应的小部分请求才会去请求DB，这样DB的压力是非常小的，是可以正常工作的

解决方案： 

1、缓存穿透

        key 对应的数据在redis中并不存在，每次针对此 key的请求从缓存获取不到，请求转发到数据库，访问量大了可能压垮数据库。比如用一个不存在的用户 id 获取用户信息，redis缓存和数据库中都没有，若黑客利用此漏洞进行攻击可能压垮数据库（黑客访问肯定不存在的数据，造成服务器压力大）。

 

解决方案： 

一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义

• 对空值缓存： 如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，这样可以缓解数据库的访问压力，然后设置空结果的过期时间会很短，最长不超过五分钟。（只能作为简单的应急方案）
• 设置可访问的名单（白名单）： 使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。
• 布隆过滤器： 将所有可能存在的数据哈希到一个足够大的 bitmaps 中，一个一定不存在的数据会被这个bitmaps 拦截掉，从而避免了对底层存储系统的查询压力
• 数据校验： 类似于用户权限的拦截，对于id=-3872这些无效访问就直接拦截，不允许这些请求到达Redis、DB上。
• 进行实时监控： 当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

注意事项：

1. 使用空值作为缓存的时候，key设置的过期时间不能太长，防止占用太多redis资源
2. 对空值缓存是一种被动的防御方式，当遇到黑客暴力请求很多不存在的数据就需要写入大量的null值到Redis中，可能导致Redis内存占用不足的情况
3. 使用布隆过滤器，可以在用户访问的时候判断该资源是否存在，不存在则直接拒绝访问
4. 布隆过滤器是有一定的误差，所以一般需要配合一些接口流量的限制（规定用户在一段时间内访问的频率）、权限校验、黑名单等来解决缓存穿透的问题 

2、缓存雪崩

        大量的key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大量并发的请求可能会瞬间把后端 DB 压垮。缓存雪崩针对很多 key 失效导致redis无法命中，数据库压力激增；缓存击穿则是某一个热门 key 失效导致redis无法命中，数据库压力激增 。

 

解决方案： 

• 构建多级缓存架构： nginx 缓存 + redis 缓存 +其他缓存（ehcache 等），程序设计较为复杂
• 使用锁或队列： 用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。效率低，不适用高并发情况
• 设置过期标志更新缓存： 记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存
• 设置缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去跟新实际的key
• 将失效时间分散开：通过使用自动生成随机数使得key的过期时间是随机的，防止集体过期

3、缓存击穿：

产生缓存雪崩的原因：redis中的某个热点key过期，但是此时有大量的用户访问该过期key

• redis正常运行，且没有出现大量的过期现象（过期后无法访问，若未命中，则需要访问数据库）
• 数据库的访问压力瞬间激增

解决方案： 

• 提前对热点数据进行设置：在 redis 高峰访问之前，把一些热门数据提前存入到redis 里面，加大这些热门数据 key 的时长
• 监控数据，适时调整： 现场监控哪些数据热门，实时调整 key 的过期时长
• 锁机制：只有一个请求可以获取到互斥锁，然后到DB中将数据查询并返回到Redis，之后所有请求就可以从Redis中得到响应