缓存穿透、缓存击穿、缓存雪崩的区别和解决方案

发布于 2024-02-20 10:50:03 字数 3033 浏览 47 评论 0

一. 前言

在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。

为了克服上述的问题，项目通常会引入 NoSQL 技术，这是一种基于内存的数据库，并且提供一定的持久化功能。

redis 技术就是 NoSQL 技术中的一种，但是引入 redis 又有可能出现缓存穿透，缓存击穿，缓存雪崩等问题。本文就对这三种问题进行较深入剖析。

二. 缓存穿透

2.1 什么是缓存穿透

key 对应的数据在数据源并不存在，每次针对此 key 的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户 id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

2.2 缓存穿透解决方案

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

伪代码：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";

    String cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    }

    cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        //数据库查询不到，为空
        cacheValue = GetProductListFromDB();
        if (cacheValue == null) {
            //如果发现为空，设置个默认值，也缓存起来
            cacheValue = string.Empty;
        }
        CacheHelper.Add(cacheKey, cacheValue, cacheTime);
        return cacheValue;
    }
}

三. 缓存击穿

3.1 什么是缓存击穿

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

3.2 缓存击穿解决方案

方式一：设置热点数据永远不过期。

方式二：互斥锁

互斥锁是业界比较常用的做法，简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去加载数据库，而是尝试获取锁，只有获取到锁的线程才能去查数据库，然后更新缓存。

public String getData(String key) {
    String value = getDataForRedis(key);
    if (value == null) {
        //尝试获取锁
        if (lock.tryLock()) {
            try {
                //查询数据库获取值
                value = getDataForDB(key);
                if (value != null) {
                    //将值放入缓存中
                    setDataRedis(key,value);
                }
            } finally {
                lock.unlock();
            }
        } else {
            Thread.sleep(20);
            getData(key);
        }
    }
}

采用互斥锁解决缓存击穿的问题时需要注意锁的粒度问题，如果所有 key 都竞争一把锁的话会导致竞争激烈，虽然不会导致数据库宕机，但是前端仍然响应缓慢。例如通过请求者 IP 的 Hash 值去散列到不同的锁上面会降低锁竞争导致的响应延迟的问题。

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间 key 是锁着的，这是过来 1000 个请求 999 个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法！

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！