redis 缓存穿透 缓存击穿 和缓存雪崩 概念和解决

• 缓存穿透

1. redis缓存穿透概念

用户查询某个数据，但该数据不存在于redis内存数据库中（缓存没有命中），这时候就会向持久层数据库查询，但数据库中也没有该数据，于是本次查询失败，

若用户很多时，他们查询的数据不存在于redis内存数据库中(缓存没有命中)，于是都去请求了持久层数据库，这样就会给持久层数据库带来很大的压力，这种大量不走redis内存数据库的现象就叫缓存穿透。

1. 缓存穿透发生的场景一般有两类：

1）

原来数据是存在的，但由于某些原因（误删除、主动清理等）在缓存和数据库层面被删除了，但前端或前置的应用程序依旧保有这些数据；

2）

恶意攻击行为，利用不存在的Key或者恶意尝试导致产生大量不存在的业务数据请求

1. 解决方案

1. 实时监控

对redis进行实时监控，当发现redis中的命中率下降的时候进行原因的排查，配合运维人员对访问对象和访问数据进行分析查询，从而进行黑名单的设置限制服务(拒绝黑客攻击)。

1. 接口校验

类似于用户权限的拦截，对于id = -3872这些无效访问就直接拦截，不允许这些请求到达Redis、DB上。

1. 布隆过滤器（BloomFilter）

在控制层做过滤，不符合条件的请求被抛弃，从而避免对持久层数据库造成的查询压力。本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。

缺点是其返回的结果是概率性的，而不是确切的。

2）缓存空对象

当查询的数据不存在于redis中时，请求到了持久层数据库中去查询数据，但查询不出数据，这时会返回空对象，同时把该空对象缓存到redis里，然后设置一个过期时间，往后只要再次请求查询该条数据，该条数据都会从redis中获取(获取redis返回的空对象)，从而保护了后端的数据源。

缺点:

①因为空对象能被缓存起来，而有些请求有可能查询不出数据，所以过程中可能产生大量的返回空对象然后被redis缓存的现象，而这意味着redis需要更多的空间来存储更多的键。

②即使对空对象设置了过期时间，但如果在redis的空对象在未过时的情况下，持久层数据库已经有了对应的数据，而redis对应的键的值仍是空对象，这时请求查询出的仍是空对象，而不是持久层里已经有的数据，而这种情况对于需要保持数据一致性的业务会造成影响。

但需要注意：

key设置的过期时间不能太长，防止占用太多redis资源，设置一个合适的TTL，比如两三分钟。

当遇到黑客暴力请求很多不存在的数据时，就需要写入大量的null值到Redis中，可能导致Redis内存占用不足的情况。

• 缓存击穿

1. redis缓存击穿概念

redis里的一个key非常热点，导致大并发集中对这个key不断的进行访问，当在这个key过期的瞬间，持续的大并发就会跳过缓存，直接作用在持久层数据库上，请求在访问持久层数据库查询数据的同时，持久层数据库也需要回写缓存，这时候就会导致持久层数据库瞬间压力过大导致服务器宕机，这种现象就叫做缓存击穿。

1. 解决方案

(1)设置热点key永不过期。

(2)加互斥锁：

使用分布式锁在redis和持久层数据库之间加锁，让每次查询都能保证只有一个线程进去，其他线程等待，这样做就能保证对于每一个key同时只能有一个线程去查询后端持久层数据库，而其他线程没有分布式锁的权限，所以只能等待，这种解决方案把高并发的压力转移到了分布式锁身上，但同时也加大了对分布式锁的考验。

【互斥锁特点】

缓存正在被建立时，其它请求会等待建立完成，速度可能较慢

用户查到的数据严格与数据库一致

（3）设置逻辑过期时间

前提：数据被建立时就加入缓存，并设置逻辑过期时间（实际缓存过期时间为 -1）

缓存未命中时，即说明数据库中不存在此数据，返回空

缓存命中时，查看逻辑过期时间是否过期，若已过期，返回已过期的数据，并在新线程中重新建立缓存并设置逻辑过期时间

【逻辑过期特点】

数据被建立时就必须加入缓存

异步建立缓存，不影响其它请求，速度较快

由于逻辑过期依然返回已过期的数据，用户查到的数据可能与数据库一致

（4）异步构建缓存

当缓存失效时，不是立刻去查询数据库，而是先创建缓存更新的异步任务，然后直接返回空值。这种做法不会阻塞当前线程，并且对于数据库的压力基本可控，但牺牲了整体数据的一致性。从实际的使用看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，所有查询返回的内容均为空值，但是对于一致性要求不高的互联网功能来说这个还是可以忍受。

• 缓存雪崩

1. redis缓存雪崩概念

在某一时间段，一批key集中过期失效或者redis宕机，导致大量的请求作用在持久层数据库上，导致持久层数据库挂掉。

1. 解决方案

1. 构建缓存高可用集群

主要针对缓存服务故障的情景，使用Redis集群来提高服务的可用性。

1. 设置缓存标记

热点数据可以不考虑失效，后台异步更新缓存，适用于不严格要求缓存一致性的情景。

1. 将失效时间分散开

常用且易于实现通过使用自动生成随机数使得key的过期时间TTL是随机的，防止集体过期。

1. 给业务添加多级缓存

使用nginx缓存 + redis缓存 + 其他缓存，不同层使用不同的缓存，可靠性更强。

1. 限流降级：

通过加锁或队列来控制读取持久层数据库的线程数量，例如通过对某个key加锁来保证只有一个线程对该key进行读和写，其他线程则需要等待。

1. 数据预热

正式部署前把可能被大量访问的数据先访问一遍，这些被访问的数据就会被加载到缓存中，在正式的大量访问到来之后减轻持久层数据库的压力；在发生大并发访问前手动触发加载缓存所需要的key，

• 注意三者的区别

1. 缓存渗透是个别key没有被命中，导致请求作用在持久层数据库上，这时影响较小
2. 缓存渗透是大量的请求作用在同一个key上，在key过期的瞬间作用在持久层服务器上，导致服务器宕机，这时影响较大
3. 缓存雪崩是一批key集中过期或redis宕机，导致持久层数据库挂掉，影响很大