从零开始SpringCloud Alibaba实战（86）——缓存击穿、缓存穿透、缓存雪崩

缓存击穿

什么时候Redis中没有要查询的数据呢？答案是过期和新增：过期：在Redis会有一个key值，每个key值都有一个ttl，也就是生命周期，一旦过期了就只能存在数据库里了；新增：插入，更新的数据还未来得及同步到Redis中。
如果线程查询一个数据库中不存在的值，此时从数据库中就返回一个空值。当一个线程不断执行同一条查询语句查询这个Redis和数据库都不存在的数据时，比如说执行上万次同一条查询语句，那么每次都穿过Redis，这样Redis就没有意义了。那么为了解决这个问题，就可以在Redis中设置空值，同一条查询语句对应的key（数据库中没有的值）都对应着一个空值，当查询其他查询语句也查询数据库中不存在的值时，都要对每个key设置一个空值，随着越来越多这样的key，Redis服务器就会承受不了这么大的压力，例如下面的例子就引出了Redis缓存穿透：

缓存击穿： 一个并发访问量比较大的key在某个时间过期，导致所有的请求直接打在DB上。

描述：某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。

缓存击穿如何解决

加锁更新

查询缓存，发现缓存中不存在，加锁，让其它线程等待，只让一个线程去更新缓存。
该方法是比较普遍的做法，即，在根据key获得的value值为空时，先锁上，再从数据库加载，加载完毕，释放锁。若其他线程发现获取锁失败，则睡眠50ms后重试。
在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。

关于互斥锁的选择，看到的大部分文章都是选择 Redis 分布式锁，因为这个可以保证只有一个请求会走到数据库，这是一种思路。

但是其实仔细想想的话，这边其实没有必要保证只有一个请求走到数据库，只要保证走到数据库的请求能大大降低即可，所以还有另一个思路是 JVM 锁。

JVM 锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。

需要注意的是，无论是使用“分布式锁”，还是“JVM 锁”，加锁时要按 key 维度去加锁。

我看网上很多文章都是使用一个“固定的 key”加锁，这样会导致不同的 key 之间也会互相阻塞，造成性能严重损耗。

单机伪代码

static Lock reenLock = new ReentrantLock();

//最后使用互斥锁的方式来实现.
  public List<String> getData() throws InterruptedException {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据
        result = getDataFromCache();
        if (result.isEmpty()) {
            if (reenLock.tryLock()) {
                try {
                    System.out.println("我拿到锁,从DB获取数据库后写入缓存");
                    // 从数据库查询数据
                    result = getDataFromDB();
                    // 将查询到的数据写入缓存
                    setDataToCache(result);
                } finally {
                    reenLock.unlock();// 释放锁
                }
            } else {//我没有拿到锁
                result = getDataFromCache();// 先查一下缓存
                if (result.isEmpty()) {
                    System.out.println("我没拿到锁,缓存也没数据,等一下");
                    Thread.sleep(100);// 
                    return getData();// 递归调用重试
                }
            }
        }
        return result;
        }

集群环境的redis的代码如下所示:

public Object getData(String key) throws InterruptedException {
    Object value = redis.get(key);
    // 缓存值过期
    if (value == null) {
        // lockRedis：专门用于加锁的redis；
        // "empty"：加锁的值随便设置都可以
        if (lockRedis.set(key, "empty", "PX", lockExpire, "NX")) {
            try {
                // 查询数据库，并写到缓存，让其他线程可以直接走缓存
                value = getDataFromDb(key);
                redis.set(key, value, "PX", expire);
            } catch (Exception e) {
                // 异常处理
            } finally {
                // 释放锁
                lockRedis.delete(key);
            }
        } else {
            // sleep50ms后，进行重试
            Thread.sleep(50);
            return getData(key);
        }
    }
    return value;
}

优点

思路简单

保证一致性

缺点

代码复杂度增大

存在死锁的风险

异步构建缓存

在这种方案下，构建缓存采取异步策略，会从线程池中取线程来异步构建缓存，从而不会让所有的请求直接怼到数据库上。该方案redis自己维护一个timeout，当timeout小于System.currentTimeMillis()时，则进行缓存更新，否则直接返回value值。

集群环境的redis代码如下所示:

String get(final String key) {  

        V v = redis.get(key);  

        String value = v.getValue();  

        long timeout = v.getTimeout();  

        if (v.timeout <= System.currentTimeMillis()) {  

            // 异步更新后台异常执行  

            threadPool.execute(new Runnable() {  

                public void run() {  

                    String keyMutex = "mutex:" + key;  

                    if (redis.setnx(keyMutex, "1")) {  

                        // 3 min timeout to avoid mutex holder crash  

                        redis.expire(keyMutex, 3 * 60);  

                        String dbValue = db.get(key);  

                        redis.set(key, dbValue);  

                        redis.delete(keyMutex);  

                    }  

                }  

            });  

        }  

        return value;  

    }

优点

性价最佳，用户无需等待

缺点

无法保证缓存一致性

热点数据不过期

直接将缓存设置为不过期，然后由定时任务去异步加载数据，更新缓存。

这种方式适用于比较极端的场景，例如流量特别特别大的场景，使用时需要考虑业务能接受数据不一致的时间，还有就是异常情况的处理，不要到时候缓存刷新不上，一直是脏数据，那就凉了。

缓存穿透

什么是缓存穿透

描述：访问一个缓存和数据库都不存在的 key，此时会直接打到数据库上，并且查不到数据，没法写缓存，所以下一次同样会打到数据库上。

此时，缓存起不到作用，请求每次都会走到数据库，流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样，起不到任何作用。

与上面讲到的缓存击穿的区别：
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

缓存穿透可能有两种原因：

自身业务代码问题
恶意攻击，爬虫造成空命中

解决方案

缓存空值/默认值

一种方式是在数据库不命中之后，把一个空对象或者默认值保存到缓存，之后再访问这个数据，就会从缓存中获取，这样就保护了数据库。

缓存空值有两大问题：

空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间（如果是攻击，问题更严重），比较有效的

方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。

例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致。

这时候可以利用消息队列或者其它异步方式清理缓存中的空对象。

布隆过滤器

除了缓存空对象，我们还可以在存储和缓存之前，加一个布隆过滤器，做一层过滤。

布隆过滤器里会保存数据是否存在，如果判断数据不不能再，就不会访问存储。

布隆过滤器的巨大用处就是，能够迅速判断一个元素是否在一个集合中。因此他有如下三个使用场景:

网页爬虫对URL的去重，避免爬取相同的URL地址

反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱（同理，垃圾短信）

缓存击穿，将已存在的缓存放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。

OK，接下来我们来谈谈布隆过滤器的原理

其内部维护一个全为0的bit数组，需要说明的是，布隆过滤器有一个误判率的概念，误判率越低，则数组越长，所占空间越大。误判率越高则数组越小，所占的空间越小。

private static BloomFilter bloomFilter =BloomFilter.create(Funnels.integerFunnel(), size);
String get(String key) {

String value = redis.get(key);

if (value == null) {

    if(!bloomfilter.mightContain(key)){
        return null;

    }else{
       value = db.get(key);  

       redis.set(key, value);  

    }

}

return value；

}

接口校验

在正常业务流程中可能会存在少量访问不存在 key 的情况，但是一般不会出现大量的情况，所以这种场景最大的可能性是遭受了非法攻击。可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的ID是正整数，则可以直接对非正整数直接过滤等等。

缓存雪崩

简单说：由于缓存不可用，导致大量请求访问后端服务，可能 mysql 扛不住高并发而打死， 像滚雪球一样，影响越来越大，最后导致整个网站崩溃不可用

分布式系统都存在这样一个问题，由于网络的不稳定性，决定了任何一个服务的可用性都不是 100% 的。当网络不稳定的时候，作为服务的提供者，自身可能会被拖死，导致服务调用者阻塞，最终可能引发雪崩连锁效应。

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力，造成数据库后端故障，从而引起应用服务器雪崩。

至于为什么会像滚雪球一样？整个与整个系统的架构有关；

redis 集群彻底崩溃：不可用

缓存服务在请求 redis 时，会有大量的线程阻塞，占用资源

超时请求失败之后，会去 mysql 查询原始数据，mysql 抗不住，被打死

源头服务由于 mysql 被打死，对源服务的请求也被阻塞，占用资源

缓存服务大量的资源全部耗费在访问 redis 和 源服务上；最后自己被拖死，无法提供服务

nginx 无法访问缓存服务，只能基于本地缓存提供服务，当缓存过期后，就耗费在访问缓存服务上

最后整个网站崩溃，页面加载不出来任何数据

雪崩效应产生的几种场景

1、缓存服务器挂了

2、高峰期缓存大面积失效

3、热点缓存失效,对热点数据持续高并发

考虑的比较完善的一套方案，分为事前、事中、事后三个层次去思考再怎么来应对缓存雪崩的场景

事前解决方案

单缓存

1.避免缓存设置相近的有效期；为有效期增加随机值；统一规划有效期，失效时间均匀分布。
2.使用互斥锁：jvm锁机制；分布式锁机制，防止热点数据持续高并发访问

限流模式

限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

超时机制设计
（1）超时分两种，一种是请求的等待超时，一种是请求运行超时。

（2）等待超时：在任务入队列时设置任务入队列时间，并判断队头的任务入队列时间是否大于超时时间，超过则丢弃任务。

（3）运行超时：直接可使用线程池提供的get方法。

双缓存方案

    主缓存：有效期按照经验值设置，主要读取的缓存，主缓存失效后从数据库加载最新值。

    备份缓存：有效期长，获取锁失败时读取的缓存，主缓存更新时需要同步更新备份缓存。

    其实就是缓存降级策略。

发生缓存雪崩之前，事情之前，怎么去避免 redis 彻底挂掉

redis本身的高可用性、复制、主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上

双机房部署，一套 redis cluster，部分机器在一个机房，另一部分机器在另外一个机房

还有一种部署方式，两套 redis cluster，两套 redis cluster 之间做一个数据的同步，redis 集群是可以搭建成树状的结构的

一旦说单个机房出了故障，至少说另外一个机房还能有些 redis 实例提供服务

事中解决方案

redis cluster 已经彻底崩溃了，已经开始大量的访问无法访问到 redis 了

ehcache 本地缓存
所做的多级缓存架构的作用上了 ，ehcache 的缓存应对零散的 redis 中数据被清除掉的现象，另外一个主要是预防 redis 彻底崩溃

多台机器上部署的缓存服务实例的内存中，还有一套 ehcache 的缓存，还能支撑一阵

对 redis 访问的资源隔离
对 redis 访问使用 hystrix 进行隔离，防止自己资源大量阻塞在访问 redis 上

对源服务访问的限流以及资源隔离
同上，防止自己资源大量阻塞在访问源服务上，同时 hystrix 在资源隔离时也做到了限流

事后解决方案

redis 数据可以恢复，之前讲解过各种备份机制，redis 数据备份和恢复，redis 重新启动起来

redis 数据彻底丢失了或者数据过旧，快速缓存预热，redis 重新启动起来

由于事中做了限流与隔离，缓存服务不会被打死，通过熔断策略 和 half-open 策略， 可以自动可以恢复对 redis 的访问，发现 redis 可以访问了，就自动恢复了

熔断降级

服务熔断：当缓存服务器宕机或超时响应时，为了防止整个系统出现雪崩，暂时停止业务服务访问缓存系统。
服务降级：当出现大量缓存失效，而且处在高并发高负荷的情况下，在业务系统内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的 fallback（退路）错误处理信息。