Redis缓存应用问题

一、缓存穿透

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案：

• 对空值缓存

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

• 设置可访问的白名单

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

• 采用布隆过滤器

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

• 进行实时监控

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

二、缓存击穿

key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期, 会从后端 DB 加载数据并回设到缓存，这时大并发的请求可能会瞬间把后端 DB 压垮

比如某个热点数据, 可能会在某些时间点, 被超高并发地访问, 容易出现缓存击穿

解决方案：

• 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长
• 实时调整： 现场监控哪些数据热门，实时调整 key 的过期时长
• 使用排他锁：就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db。 先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX）去 set 一个 mutex key ，当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key； 当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法

三、缓存雪崩

在极短时间内, 访问大量 Key, 而这些 Key 集中过期，缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存，前者则是某一个key。

解决方案：

• 构建多级缓存架构 nginx 缓存 + redis 缓存 +其他缓存（ehcache 等） , 这种方式开发/维护成本较高
• 用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
• 设置过期标志更新缓存 ：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际 key 的缓存
• 将缓存失效时间分散开： 比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件