当前位置:   article > 正文

【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案

缓存雪崩

一、缓存穿透

1.1 产生原因

客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会访问数据库。导致DB的压力瞬间变大而卡死或者宕机。

  • 大量的高并发的请求打在redis上
  • 这些请求发现redis上并没有需要请求的资源,redis命中率降低
  • 因此这些大量的高并发请求转向DB请求对应的资源
  • DB压力瞬间增大,直接将DB打垮,进而引发一系列“灾害”

缓存穿透发生的场景一般有两类:

  • 原来数据是存在的,但由于某些原因(误删除、主动清理等)在缓存和数据库层面被删除了,但前端或前置的应用程序依旧保有这些数据;
  • 恶意攻击行为,利用不存在的Key或者恶意尝试导致产生大量不存在的业务数据请求。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jACPoikM-1688634946898)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230705214531919.png)]

1.2 解决方法

接口校验

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

对空值进行缓存

比如,虽然数据库中没有id = 1022的用户的数据,但是在redis中对其进行缓存(key=1022, value=null),这样当请求到达redis的时候就会直接返回一个null的值给客户端,避免了大量无法访问的数据直接打在DB上。

但需要注意:

  • key设置的过期时间不能太长,防止占用太多redis资源,设置一个合适的TTL,比如两三分钟。
  • 当遇到黑客暴力请求很多不存在的数据时,就需要写入大量的null值到Redis中,可能导致Redis内存占用不足的情况。

使用布隆过滤器

一个很清晰的视频,十分钟以内就能看完:布隆过滤器Bilibili视频讲解
在这里插入图片描述

布隆过滤器的基本原理:使用BitMap结构和多个哈希函数,向其中加入数据 x x x时,将 h a s h 1 ( x ) hash_1(x) hash1(x) h a s h 2 ( x ) hash_2(x) hash2(x) h a s h 3 ( x ) hash_3(x) hash3(x)等位置的bit值置为1。查询时,如果相应的位置均为1,则认为该数据存在于布隆过滤器中。性能较高但也有缺点:

  • 可能会存在误判,使用时误判率可以作为参数进行设置,其实是调节了这个过程中使用到的哈希函数,使用的哈希函数越多,被误判的可能性越小,但相应地,判断过程会越慢。通常建议值是 1%。
  • 不易于进行数据的删除操作,因为两个不同数据,可能会在某一个哈希函数上具有相同的哈希值
  • 欲使其发挥作用,需要将MySQL中可能出现的所有参数、即全量数据都存入布隆过滤器中,代价较大

如果它告诉你不存在,则一定不存在;如果它告诉你存在,则可能不存在。
插一句:很适合判断海量元素中元素是否存在,比如设置网站的黑名单

使用BitMap作为布隆过滤器,将目前所有可以访问到的资源通过简单的映射关系放入到布隆过滤器中(哈希计算),当一个请求来临的时候先进行布隆过滤器的判断,如果有那么才进行放行,否则就直接拦截。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XmeWjaTb-1688634946899)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230705220925615.png)]

实时监控

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

二、缓存雪崩

当redis中的大量key集体过期,可以理解为Redis中的大部分数据都清空 / 失效了,这时候如果有大量并发的请求来到,Redis就无法进行有效的响应(命中率急剧下降),也会导致DB先生的绝望。

缓存雪崩的场景通常有两个:

  • 大量热点key同时过期
  • 缓存服务故障或宕机

2.2 解决方法

将失效时间分散开

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

给业务添加多级缓存

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

构建缓存高可用集群

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

使用锁或者队列的方式

如果查不到就加上排它锁,其他请求只能进行等待,但这种方式可能影响并发量。

设置缓存标记

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

三、缓存击穿

Redis中的某个热点key过期,但是此时有大量的用户访问该过期key。

可以看成缓存雪崩的一个特殊子集。

比如xxx塌房哩、xxx商品活动,这时候大量用户都在访问该热点事件,但是可能优于某种原因,redis的这个热点key过期了,那么这时候大量高并发对于该key的请求就得不到redis的响应,那么就会将请求直接打在DB服务器上,导致整个DB瘫痪。

3.2 解决方法

使用互斥锁

只有一个请求可以获取到互斥锁,然后到DB中将数据查询并返回到Redis,之后所有请求就可以从Redis中得到响应。【缺点:所有线程的请求需要一同等待】

”提前“使用互斥锁 / 逻辑过期

在value内部设置一个比缓存(Redis)过期时间短的过期时间标识,当异步线程发现该值快过期时,马上延长内置的这个时间,并重新从数据库加载数据,设置到缓存中去。【缺点:不保证一致性,实现相较互斥锁更复杂】

提前对热点数据进行设置

类似于新闻、某博等软件都需要对热点数据进行预先设置在Redis中,或者适当延长Redis中的Key过期时间。

监控数据,适时调整

监控哪些数据是热门数据,实时的调整key的过期时长。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3p28T6My-1688634946899)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230705223722624.png)]

3.3 实现

1 互斥锁

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vebCChYc-1688634946900)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230705224115044.png)]

使用setnx作为Redis中的锁。

  • Redis中查询缓存
    • 存在且不为空值,直接返回
    • 为空值(比如“”、0等特殊值),返回失败结果
    • 不存在,获取锁
  • 获取锁失败,等待重试
  • 获取成功,查找MySQL
    • 不存在,Redis存入空值
    • 存在,写入Redis
  • 释放锁,返回结果
    /**
     * 根据id查找商户,先到redis中找,再到MySQL中找
     * @param id
     * @return
     */
    @Override
    public Result queryShopById(Long id) {

        // 用String形式存储JSON
        String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);

        // 如果查询结果不为null,直接返回
        if (StrUtil.isNotBlank(shopJson)) {
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }

        // 否则Redis中查询结果为空,判断是否为“”
        if (shopJson != null) {
            return Result.fail("店铺不存在,请确认id是否正确");
        }

        // 尝试获取锁,
        // 如果没有得到锁,Sleep一段时间
        if (!tryLock(LOCK_SHOP_KEY + id)) {
            try {
                Thread.sleep(50);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            // 从开始重试
            return queryShopById(id);
        }

        // 获得了锁,从MySQl中查找
        Shop shop = this.getById(id);
        // 模拟重建的延时
        try {
            Thread.sleep(200);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 不在MySQL中
        if (shop == null) {
            // 将空值写入Redis
            stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
            // 释放锁
            unLock(LOCK_SHOP_KEY + id);
            return Result.fail("店铺不存在,请确认id是否正确");
        }
        else {
            // 在MySQL中,存入redis
            stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shop), CACHE_SHOP_TTL, TimeUnit.MINUTES);
            // 释放锁
            unLock(LOCK_SHOP_KEY + id);
            return Result.ok(shop);
        }
    }

    public boolean tryLock(String key) {
        // 尝试获取锁,set成功返回true,否则返回false
        Boolean getLock = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
        // 避免getLock为null,使用工具类
        return BooleanUtil.isTrue(getLock);
    }

    public void unLock(String key) {
        stringRedisTemplate.delete(key);
    }


  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71

测试

F:\Jmeter\bin\ApacheJMeter.jar
  • 1

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uo5t40vQ-1688634946900)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230706153638543.png)]

对应地,MySQL只执行了1次SQL:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6nAJ3Gg8-1688634946900)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230706153739245.png)]

2 逻辑过期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WsYMPuEj-1688634946900)(【Redis】缓存穿透、缓存击穿、缓存雪崩的原因及解决方案/image-20230706160509947.png)]

    /**
     * 线程池
     */
    private static final ThreadFactory NAMED_THREAD_FACTORY = new ThreadFactoryBuilder().build();

    private static final ExecutorService POOL = new ThreadPoolExecutor(5, 200,
            0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(1024), NAMED_THREAD_FACTORY,
            new ThreadPoolExecutor.AbortPolicy());


    public Result queryWithExpire(Long id) {
        String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);

        // 如果查询结果为null,直接失败
        if (StrUtil.isBlank(shopJson)) {
            return Result.fail("您查询的数据不存在,请检查您的输入");
        }

        RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);
        Shop shop = JSONUtil.toBean((JSONObject)redisData.getData(), Shop.class);
        // 判断缓存是否过期
        LocalDateTime time = redisData.getExpireTime();
        // 未过期,直接返回信息
        if (time.isAfter(LocalDateTime.now())) {
            return Result.ok(shop);
        }
        // 过期,获取互斥锁失败,返回过期信息
        if (!tryLock(LOCK_SHOP_KEY + id)) {
            unLock(LOCK_SHOP_KEY + id);
            return Result.ok(shop);
        }
        // 过期,获取互斥锁成功,开启新线程,重建数据库
       POOL.submit(() -> {
           this.saveShop2Redis(id, 20L);
           unLock(LOCK_SHOP_KEY + id);
       });
       // 返回过期信息
       return Result.ok(shop);
    }

	/**
     * 在MySQL中查找id的shop,写入Redis并更新虚拟过期时间
     * @param id
     * @param expireSeconds
     */
    private void saveShop2Redis(Long id, Long expireSeconds) {
        // 获取
        Shop shop = this.getById(id);

        // 封装
        RedisData redisData = new RedisData();
        redisData.setData(shop);
        redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));

        // 写入Redis
        stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/496830
推荐阅读
相关标签
  

闽ICP备14008679号