【分布式】缓存穿透、缓存雪崩，缓存击穿解决方案

时间 2019-12-10

原文原文链接

1、什么样的数据适合缓存

2、缓存穿透

缓存穿透是指查询一个必定不存在的数据，因为缓存是不命中时须要从数据库查询，查不到数据则不写入缓存，这将致使这个不存在的数据每次请求都要到数据库去查询，形成缓存穿透。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击咱们的应用，这就是漏洞。html

解决方案：redis

1）有不少种方法能够有效地解决缓存穿透问题，最多见的则是采用布隆过滤器，将全部可能存在的数据哈希到一个足够大的bitmap中，一个必定不存在的数据会被这个bitmap拦截掉，从而避免了对底层数据库的查询压力。数据库

2）另外也有一个更为简单粗暴的方法，若是一个查询返回的数据为空（不论是数据不存在，仍是系统故障），仍然把这个空结果进行缓存，但它的过时时间会很短，最长不超过五分钟。后端

3、缓存雪崩：

缓存雪崩是指在设置缓存时采用了相同的过时时间，致使缓存在某一时刻同时失效，致使全部的查询都落在数据库上，形成了缓存雪崩。缓存

解决方案：并发

1）在缓存失效后，经过加锁或者队列来控制读数据库写缓存的线程数量。好比对某个key只容许一个线程查询数据和写缓存，其余线程等待。分布式

2）能够经过缓存reload机制，预先去更新缓存，在即将发生大并发访问前手动触发加载缓存。高并发

3）不一样的key，设置不一样的过时时间，让缓存失效的时间点尽可能均匀。spa

4）作二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，能够访问A2，A1缓存失效时间设置为短时间，A2设置为长期。线程

4、缓存击穿

对于一些设置了过时时间的key，若是这些key可能会在某些时间点被超高并发地访问，是一种很是“热点”的数据。这个时候，须要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是不少key。
缓存在某个时间点过时的时候，刚好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过时通常都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案：

1）后台刷新

后台定义一个job(定时任务)专门主动更新缓存数据.好比,一个缓存中的数据过时时间是30分钟,那么job每隔29分钟定时刷新数据(将从数据库中查到的数据更新到缓存中).

注：这种方案比较容易理解，但会增长系统复杂度。比较适合那些 key 相对固定,cache 粒度较大的业务，key 比较分散的则不太适合，实现起来也比较复杂。

2）检查更新

将缓存key的过时时间(绝对时间)一块儿保存到缓存中(能够拼接,能够添加新字段,能够采用单独的key保存..无论用什么方式,只要二者创建好关联关系就行).在每次执行get操做后,都将get出来的缓存过时时间与当前系统时间作一个对比,若是缓存过时时间-当前系统时间<=1分钟(自定义的一个值),则主动更新缓存.这样就能保证缓存中的数据始终是最新的(和方案一同样,让数据不过时.)

注：这种方案在特殊状况下也会有问题。假设缓存过时时间是12:00，而 11:59 到 12:00这 1 分钟时间里刚好没有 get 请求过来，又刚好请求都在 11:30 分的时候高并发过来，那就悲剧了。这种状况比较极端，但并非没有可能。由于“高并发”也多是阶段性在某个时间点爆发。

3）分级缓存

采用 L1 (一级缓存)和 L2(二级缓存) 缓存方式，L1 缓存失效时间短，L2 缓存失效时间长。请求优先从 L1 缓存获取数据，若是 L1缓存未命中则加锁，只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 L1 缓存和 L2 缓存中，而其余线程依旧从 L2 缓存获取数据并返回。

注：这种方式，主要是经过避免缓存同时失效并结合锁机制实现。因此，当数据更新时，只能淘汰 L1 缓存，不能同时将 L1 和 L2 中的缓存同时淘汰。L2 缓存中可能会存在脏数据，须要业务可以容忍这种短期的不一致。并且，这种方案可能会形成额外的缓存空间浪费。

4）加锁

方法1：

// 方法1:
    public synchronized List<String> getData01() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据
        result = getDataFromCache();
        if (result.isEmpty()) {
            // 从数据库查询数据
            result = getDataFromDB();
            // 将查询到的数据写入缓存
            setDataToCache(result);
        }
        return result;
    }

注：这种方式确实可以防止缓存失效时高并发到数据库,可是缓存没有失效的时候,在从缓存中拿数据时须要排队取锁,这必然会大大的下降了系统的吞吐量.

方法2：

// 方法2:
    static Object lock = new Object();
 
    public List<String> getData02() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据
        result = getDataFromCache();
        if (result.isEmpty()) {
            synchronized (lock) {
                // 从数据库查询数据
                result = getDataFromDB();
                // 将查询到的数据写入缓存
                setDataToCache(result);
            }
        }
        return result;
    }

注：这个方法在缓存命中的时候,系统的吞吐量不会受影响,可是当缓存失效时,请求仍是会打到数据库,只不过不是高并发而是阻塞而已.可是,这样会形成用户体验不佳,而且还给数据库带来额外压力.

方法3：

//方法3
    public List<String> getData03() {
        List<String> result = new ArrayList<String>();
        // 从缓存读取数据
        result = getDataFromCache();
        if (result.isEmpty()) {
            synchronized (lock) {
            //双重判断,第二个以及以后的请求没必要去找数据库,直接命中缓存
                // 查询缓存
                result = getDataFromCache();
                if (result.isEmpty()) {
                    // 从数据库查询数据
                    result = getDataFromDB();
                    // 将查询到的数据写入缓存
                    setDataToCache(result);
                }
            }
        }
        return result;
    }

注：双重判断虽然可以阻止高并发请求打到数据库,可是第二个以及以后的请求在命中缓存时,仍是排队进行的.好比,当30个请求一块儿并发过来,在双重判断时,第一个请求去数据库查询并更新缓存数据,剩下的29个请求则是依次排队取缓存中取数据.请求排在后面的用户的体验会不爽.

方法4：

static Lock reenLock = new ReentrantLock();
 
    public List<String> getData04() 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 getData04();// 重试
                }
            }
        }
        return result;
    }

注：最后使用互斥锁的方式来实现，能够有效避免前面几种问题.

固然,在实际分布式场景中，咱们还可使用 redis、tair、zookeeper 等提供的分布式锁来实现.可是,若是咱们的并发量若是只有几千的话,何须杀鸡焉用牛刀呢?

转自：https://www.cnblogs.com/dream-to-pku/p/9153999.html