了解 Redis 缓存穿透、缓存击穿、缓存雪崩

了解 Redis 缓存穿透、缓存击穿、缓存雪崩 1. 缓存穿透

是指查询一个根本不存在的数据，缓存层和存储层都不会命中，如果从存储层查不到数据则不写入缓存层。

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。

通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

1.1 原因分析

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

1、自身业务代码或者数据出现问题

比如，我们数据库的 id 都是 1 开始自增上去的，如发起为 id 值为 -1 的数据或 id 为特别大不存在的数据。如果不对参数做校验，数据库 id 都是大于 0 的，我一直用小于 0 的参数去请求，每次都能绕开 Redis 直接打到数据库，此时数据库也查不到，每次都这样，并发高点就容易崩掉了。

2、恶意攻击、爬虫等造成大量空命中

1.2 解决方案

对于缓存穿透的解决可以从以下几个方面入手：

1、增加校验

如用户鉴权校验，id 做基础校验，id<=0 的直接拦截；

2、缓存空对象

既然本来都是不存在的数据，那就把空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。

但是这样会存在 2 个问题：

空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间(如果是攻击，问题更严重)，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用数据一致性方案处理。

3、布隆过滤器

在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。

例如：一个推荐系统有 4 亿个用户 id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户 id 不存在，那么就不会访问存储层，在一定程度保护了存储层。

这种方法适用于数据命中不高、数据相对固定、实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

2. 缓存击穿

缓存击穿是指一个热点 key，大并发集中对这一个点进行访问，当这个 key 在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

缓存击穿的话，设置热点数据永远不过期。或者加上互斥锁就能搞定了。

2.1 原因分析

设置了过期时间的 key，承载着高并发，是一种热点数据。从这个 key 过期到重新从 MySQL 加载数据放到缓存的一段时间，大量的请求有可能把数据库打死。

缓存雪崩是指大量缓存失效，缓存击穿是指热点数据的缓存失效。

2.2 解决方案

1、使用互斥锁

业界比较常用的做法，是使用互斥锁。

简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db，而是先使用缓存工具的某些带成功 *** 作返回值的 *** 作（比如 Redis 的 SETNX 或者 Memcache 的 ADD）去 set 一个 mutex key，当 *** 作返回成功时，再进行 load db 的 *** 作并回设缓存，否则，就重试整个 get 缓存的方法。

伪代码如下：

public String get(key) {
    String value = redis.get(key);
    if (value == null) {//代表缓存值过期
        // 设置 3min 的超时，防止 del  *** 作失败的时候，下次缓存过期一直不能 load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {
            //代表设置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        } else {
            //这个时候代表同时候的其他线程已经 load db 并回设到缓存了，这时候重试获取缓存值即可
            sleep(50);
            get(key); //重试
        }
    } else {
        return value;
    }
}

2、永不过期

这里的永不过期包含两层意思：

从 Redis 上看，确实没有设置过期时间，这就保证了，不会出现热点 key 过期问题，也就是物理不过期。从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在 key 对应的 value 里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是逻辑不过期。

从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程（非构建缓存的线程）可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

3. 缓存雪崩

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至宕机。

3.1 原因分析

由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务，比如同一时间缓存数据大面积失效，那一瞬间 Redis 跟没有一样，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。

3.2 解决方案

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

保证缓存层服务高可用性

和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用；

设置 key 永不失效（热点数据）；

设置 key 缓存失效时候尽可能错开；

使用多级缓存机制，比如同时使用 Redis 和 Memcache 缓存，请求->redis->memcache->db。