Redis缓存穿透-击穿-雪崩详细分析加解决办法

Redis

缓存穿透

问题描述-如图

缓存穿透的原因

1. key 对应的数据在数据源并不存在，每次针对此key 的请求从缓存获取不到，请求都会压到数据源, 可能压垮数据源
2. 比如: 用一个不存在的用户id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库
3. 也就是说：如果从存储层查不到数据则不会写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询, 失去了缓存的意义

缓存穿透的现象/表象

1. 应用服务器压力变大

2. Redis 命中率降低

3. 一直查数据库

解决方案/思路

对空值缓存

如果一个查询返回的数据为空，我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间应该短些，最长不超过五分钟

设置可访问的名单(白名单)

定义一个可以访问的名单，每次访问和白名单的id 进行比较，如果访问id 不在白名单里面，进行拦截，不允许访问, 比如使用bitmaps 实现.

采用布隆过滤器

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难

进行实时监控

当发现Redis 的命中率开始急速降低, 需要排查访问对象和访问的数据, 和运维人员配合,可以设置黑名单限制服务

缓存击穿

问题描述-如图

缓存击穿的原因

1. key 对应的数据存在，但在redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期, 会从后端DB 加载数据并回设到缓存，这时大并发的请求可能会瞬间把后端DB 压垮
2. 比如某个热点数据, 可能会在某些时间点, 被超高并发地访问, 容易出现缓存击穿

缓存击穿的现象/表象

1. 数据库访问压力瞬时增加
2. Redis 里面没有出现大量key 过期
3. Redis 正常运行状态, 但是数据库可能瘫痪了

解决方案

预先设置热门数据

在redis 高峰访问之前，把一些热门数据提前存入到redis 里面，加大这些热门数据key 的时长

实时调整

现场监控哪些数据热门，实时调整key 的过期时长

使用锁

• 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

• 先使用缓存工具的某些带成功操作返回值的操作（比如Redis 的SETNX）去set 一个mutex key

• 当操作返回成功时，再进行load db 的操作，并回设缓存,最后删除mutex key；

• 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get 缓存的方法

• 使用锁效率会有影响

缓存雪崩

问题描述-如图

缓存雪崩的原因

1. key 对应的数据存在，但在redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB 加载数据并回设到缓存
2. 这个时候大并发的请求可能会瞬间把后端DB 压垮。
3. 缓存雪崩与缓存击穿的区别在于这里针对很多key 缓存，前者则是某一个key

缓存雪崩的现象/表象

1. 数据库访问压力变大, 服务器崩溃
2. 在极短时间内, 访问大量Key, 而这些Key 集中过期

解决方案/思路

构建多级缓存架构

nginx 缓存+ redis 缓存+其他缓存（ehcache 等） , 这种方式开发/维护成本较高

使用锁或队列

用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

设置过期标志更新缓存

记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key 的缓存。

将缓存失效时间分散开

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件