Redis缓存架构详解

news2024/12/25 0:39:59

文章目录

  • Redis缓存结构详解
  • 前言
    • Redis 缓存架构
    • redis 和db数据一致性
      • 先写db还是写redis
      • 如果是先写db,再删除缓存呢?
      • 延迟双删
    • 简单的缓存,并发不高,没啥流量
    • 简单的缓存,并发高,但是存在redis和 Db 双写不一致,读写并发不一致问题
        • 解决方案 1
        • 解决方案 2
        • 解决方案 3
          • 读写锁
    • 缓存构建
        • 解决方案 1 加分布式锁
        • 解决方案 2 dcl 双重校验
        • 解决方案 3 定时器兜底
      • 双重校验以及防止大流量从缓存构建
    • 多级缓存
    • 缓存穿透
      • 方案 1
      • 方案 2
    • 缓存雪崩

Redis缓存结构详解

前言

一般开发中我们都会使用 Redis 作缓存,提高查询效率,但 Redis 缓存在使用时还会有很多问题,如,缓存穿透,击穿,雪崩等。
一般对于不同的业务我们使用不同的缓存结构。

  • 1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等),这种几乎不用考虑这个问题,很少会发生 缓存不一致,可以给缓存数据加上过期时间,每隔一段时间触发读的主动更新即可。

  • 2、就算并发很高,如果业务上能容忍短时间的缓存数据不一致(如商品名称,商品分类菜单等),缓存加上过期 时间依然可以解决大部分业务对于缓存的要求。

  • 3、如果不能容忍缓存数据不一致,可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队,读读的 时候相当于无锁。

  • 4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存,但是引入了新的中间件,增加 了系统的复杂度。

Redis 缓存架构

首先,我们在开发中经常这么写,先从 redis 查询,redis没有再从db查,一般都是这么写的,但是不同业务对数据一致性和实时性要求很高,一些业务又不需要特别强的一致性,有一些又需要强一致性,对此我们再使用 Redis 做缓存时候需要针对不同业务提供不同的缓存架构。

这里逐步对数据一致性和性能以及并发问题,用 Redis 做为缓存,针对不同业务模型使用 Redis逐级递增。

redis 和db数据一致性

先写db还是写redis

先更新redis还是先更新db,无论更新那个都存在问题。

1 双写不一致

在这里插入图片描述

线程 1 写数据稍微慢点,中间有线程 2 更新成功,此时线程 1 再更新成功,对于线程 2 来说缓存还是旧数据,同理先更新reids再db也是一样的。

如果是先写db,再删除缓存呢?

读写并发不一致问题
在这里插入图片描述
t1 更新 a=7提交成功,删除缓存,t2更新a=6删除db,此时 t2 还没提交事务,t3查缓存a=7 ,此时t2在t3更新缓存之前更新成功同时也删除缓存,t3最后更新了缓存。缓存数据还是7 相比t2操作就是脏数据了。

那该如何更新缓存呢?

延迟双删

在这里插入图片描述

延迟双删,先更新db,再删除缓存,隔几秒再删除缓存,但是这中间几秒如果有别的节点可能又接着改库了,所以更新缓存貌似没啥意义,删除就好了,最大程度保证缓存和数据库数据一致。

中间这几秒数据不一致,之后重建缓存,尽可能保证数据源一致,但是这几秒的业务逻辑是有问题的。

  • Bin log更新缓存

利用bin log mq 异步重试更新

但是一般来说具体的业务使用不同的方案,很少有哪种方法是完美的,都是各种因素综合考虑下来认为相对较优的解。

简单的缓存,并发不高,没啥流量

首先简单的缓存,并发不高,没啥流量,代码如下:

更新放缓存

    @Transactional
    public Product update(Product product) {
        Product productResult = productDao.update(product);
        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
                genProductCacheTimeout(), TimeUnit.SECONDS);

        return productResult;
    }

也不怎么关心缓存是否更新成功,本来业务就没啥流量,更不怎么去关心数据一致性问题。

    //从缓存读
    public Product get1(Long productId) throws InterruptedException {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
        }

        product = productDao.create(product);
        if (product == null) {
            return null;
        }

		//更新缓存
        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                genProductCacheTimeout(), TimeUnit.SECONDS);

        return product;
    }

如果流量稍微大点或者间接性有请求,不想从db读,尽量从redis读取,可以将时间设置久点,也可以每次进来就续期,延长缓存时间。

从缓存读 并且 读延期

    //从缓存读 并且 读延期
    public Product get2(Long productId) throws InterruptedException {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return new Product();
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }
        return product;
    }

简单的缓存,并发高,但是存在redis和 Db 双写不一致,读写并发不一致问题

如果对实时性要求不高,直接设置缓存时间即可

如果对实时性要求高:

  • 1 如果稍微对实时性要求比较高,可以允许短时间内的不一致,设置缓存时间(设置短一点即可)
  • 2 延迟双删策略,读的时候从新加载,短时间内读的旧数据.可以接受
  • 3 一点也不能接受,加分布式锁,强一致性
  • 4 binlog订阅 ,mq 更新

解决方案 1

缓存设置时间

    public Product get1(Long productId) throws InterruptedException {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return new Product();
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }
        return product;
    }

解决方案 2

延迟双删策略,读的时候从新加载,短时间内读的旧数据.可以接受

更新修改缓存

    @Transactional
    public Product update2(Product product) {
        Product productResult = productDao.update(product);
        //这里先删除
        redisUtil.del(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId());
        //ToDo 延迟几秒后可以再删除一次 防止删除失败或者另一个线程进来也操作更新数据
        //这里用线程异步模拟删除
        new Thread(()->{
            redisUtil.del(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId());
        }).start();
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return productResult;
    }

读数据和上面一致

    public Product get2(Long productId) throws InterruptedException {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }

        product = productDao.create(product);
        if (product == null) {
            // //读延期
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
            return null;
        }
        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                genProductCacheTimeout(), TimeUnit.SECONDS);
        return product;
    }

解决方案 3

加分布式锁,强一致性
这里分布式锁不考虑使用哪个,不在本文讨论,具体查redis分布式锁
这里我用的是redisson 分布式锁

更新缓存

   //todo  这里应该先加锁,再开事务
    @Transactional
    public Product update3(Product product) {
        RLock lock = redisson.getLock("product:" + product.getId());
        //加锁尽量加时间
        //lock.lock();
        lock.lock(5,TimeUnit.SECONDS);
        Product productResult;
        try {
             productResult = productDao.update(product);
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
                    genProductCacheTimeout(), TimeUnit.SECONDS);
        }finally {
            lock.unlock();
        }
        return productResult;
    }

加分布式锁,并发过程中还是会读到旧数据,读写不互斥

多个线程下,有一个更新缓存,其他的并行读取的还是旧数据。
当然你也可以给读加锁,但是读性能就下降了。没必要。对此需要使用读写锁

    public Product get3(Long productId) throws InterruptedException {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }

        product = productDao.create(product);
        if (product == null) {
            // //读延期
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
            return null;
        }
        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                genProductCacheTimeout(), TimeUnit.SECONDS);
        return product;
    }
读写锁

加分布式锁,强一致性,读写锁互斥,写操作读阻塞,防止并发读旧数据。

//todo  应该先加锁,再开事务
    @Transactional
    public Product update3_1(Product product) {
        RReadWriteLock lock = redisson.getReadWriteLock("product:" + product.getId());
        //加锁
        RLock rLock = lock.writeLock();
        rLock.lock(5,TimeUnit.SECONDS);
        Product productResult;
        try {
            productResult = productDao.update(product);
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
                    genProductCacheTimeout(), TimeUnit.SECONDS);
        }finally {
            rLock.unlock();
        }
        return productResult;
    }

读取数据
此时,更新数据的时候,其他读线程会阻塞,直到更新成功,读读不回互斥,读读根本就没有数据变化,也就不存在竞争条件了。

读写锁请参考aqs里的java读写锁,原理是一样的,只不过redis redisson基于分布式封装了一个分布式场景的

    public Product get3_1(Long productId) throws InterruptedException {

        RReadWriteLock lock = redisson.getReadWriteLock("product:" + productId);
        //加锁
        RLock rLock = lock.readLock();
        Product product = null;
        rLock.lock(5,TimeUnit.SECONDS);
        try {

            String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
            String productStr = redisUtil.get(productCacheKey);
            if (!StringUtils.isEmpty(productStr)) {
                if (EMPTY_CACHE.equals(productStr)) {
                    // //读延期
                    redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                    return null;
                }
                product = JSON.parseObject(productStr, Product.class);
                redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
            }

            product = productDao.create(product);
            if (product == null) {
                // //读延期
                redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                    genProductCacheTimeout(), TimeUnit.SECONDS);

        }finally {
            rLock.unlock();
        }
        return product;
    }

缓存构建

以上缓存,前提是缓存里有数据,不会访问缓存,如果说某一瞬间,缓存里数据都没有或者某个商品没有缓存,瞬时进来大量的流量,直接缓存击穿,并发高大量线程同时查询db,严重可能会直接打满db,造成后端服务出故障。

对于这种问题,我们需要防止出现此类问题,尽量让少部分线程打到db,或者让少部分线程去 Db查然后构建到redis里。

解决办法:

  • 1 加分布式锁
  • 2 dcl 双重校验
  • 3 定时器兜底

解决方案 1 加分布式锁

防止大流量进来从db构建缓存,但是没有解决缓存不一致问题,双写问题,以及并发读写问题不一致问题(这里不考虑,需要请看上面实例哦)

 public Product get0(Long productId) throws InterruptedException {
        Product product = null;
        product = getProductFromRedis(productId, product);
        if (product == null) return null;


        RLock lock = redisson.getLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
        lock.lock(5, TimeUnit.SECONDS);

        

        try {

            product = productDao.create(product);
            if (product == null) {
                // //读延期
                redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                    genProductCacheTimeout(), TimeUnit.SECONDS);
        } finally {
            lock.unlock();
        }


        return product;
    }

解决方案 2 dcl 双重校验

但加个分布式锁,确实是能解决,但是并发高的情况下,还是会有很多线程先去查redis,缓存没查到,会加锁,再排队走db。这把锁感觉没加似的,这个有没很像我们单例模式哪里?对此可以参考dcl 单例模式哪里去解决,在锁里再去判断一下,后面就不会再走db了。

    //dcl 双重校验 防止大流量从db构建缓存
    public Product get1(Long productId) throws InterruptedException {
        Product product = null;
        product = getProductFromRedis(productId, product);
        if (product == null) return null;


        RLock lock = redisson.getLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
        lock.lock(5, TimeUnit.SECONDS);

        //dcl  校验从缓存里获取
        product = getProductFromRedis(productId, product);
        if (product == null) return null;

        try {

            product = productDao.create(product);
            if (product == null) {
                // //读延期
                redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                    genProductCacheTimeout(), TimeUnit.SECONDS);
        } finally {
            lock.unlock();
        }


        return product;
    }

但目前很多线程这里排队等待,之后还是会走加锁这个逻辑。

在这里插入图片描述

1w 个线程在这里lock,然后串行,这得多慢。
解决这种办法,我们可以让试着获取锁,没获取到就从缓存里查,只要有一个线程构建成功,之后根本就不需要加锁了,直接从缓存查就 Ok…

 lock.tryLock(5, TimeUnit.SECONDS);

尝试获取锁,其实也会存在问题,如果都没获取到,还是会走db查询,但这种也不大可能,大概不会出现这种问题,除非db特别拉胯,一个线程拿到锁,构建缓存构建半天…

加锁和尝试加锁都有一些优点和缺点,这种问题出现的概率一般不大,具体问题具体对待,没有哪一种方案是特别完美的。

解决方案 3 定时器兜底

有些业务缓存场景查询,可以用定时器去查结果然后缓存到redis里
有那么一段时间缓存里可能没预热数据,也可以用定时器去定时job跑数据,存redis里。

双重校验以及防止大流量从缓存构建

上面单独防止大流量从缓存构建 , 读写锁数据强一致性

组合起来就是既能强一致性又能防止大流量从db构建缓存

读缓存

public Product get2(Long productId) throws InterruptedException {
        Product product = null;
        product = getProductFromRedis(productId, product);
        if (product == null) return null;

        RLock lock = redisson.getLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
        lock.lock(5, TimeUnit.SECONDS);

        try {

            //dcl  校验从缓存里获取
            product = getProductFromRedis(productId, product);
            if (product == null) return null;

            RReadWriteLock readWriteLock = redisson.getReadWriteLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
            RLock readLock = readWriteLock.readLock();
            readLock.lock(5,TimeUnit.SECONDS);
             try {
                 product = productDao.create(product);
                 if (product == null) {
                     // //读延期
                     redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
                     return null;
                 }
                 redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                         genProductCacheTimeout(), TimeUnit.SECONDS);
             }finally {
                 readLock.unlock();
             }
        } finally {
            lock.unlock();
        }

        return product;
    }

更新缓存

    public Product update2(Product product) {
        Product productResult;
        RReadWriteLock readWriteLock = redisson.getReadWriteLock(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId());
        RLock writeLock = readWriteLock.writeLock();
        writeLock.lock(5, TimeUnit.SECONDS);
        try {
            productResult = productDao.update(product);
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
                    genProductCacheTimeout(), TimeUnit.SECONDS);
        } finally {
            writeLock.unlock();
        }

        return productResult;
    }

多级缓存

我们都知道单台 redis 节点 可以抗10w 并发,像一些场景,某个直播带货,一个冷门商品,突然爆火了,瞬时 几千万流量进来,redis根本扛不住,如果我们将数据缓存到jvm里呢?

设置jvm本地缓存,以及及时更新本地缓存(用mq或者 bin log订阅,会有一点点延迟,可以接受),如果再扛不住,扩容和限流…

    //ToDo 这里用map 模拟, 应该用淘汰策略的jvm本地缓存框架,如spring cache , Guava Cache
    public static final Map<String,Object> LOCAL_CACHE = new ConcurrentHashMap<>();

构建缓存

    public Product create3(Product product) {
        Product productResult;
        RReadWriteLock readWriteLock = redisson.getReadWriteLock(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId());
        RLock writeLock = readWriteLock.writeLock();
        writeLock.lock(5, TimeUnit.SECONDS);
        try {
            productResult = productDao.create(product);
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
                    genProductCacheTimeout(), TimeUnit.SECONDS);

            LOCAL_CACHE.put(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(),product);
        } finally {
            writeLock.unlock();
        }

        return productResult;
    }

读取缓存

 public Product get3(Long productId) throws InterruptedException {
        Product product = null;
        product = getProductFromRedisAndLoclCache(productId, product);
        if (product == null) return null;

        RLock lock = redisson.getLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
        lock.lock(5, TimeUnit.SECONDS);

        //dcl  校验从缓存里获取
        product = getProductFromRedisAndLoclCache(productId, product);
        if (product == null) return null;

        try {
            RReadWriteLock readWriteLock = redisson.getReadWriteLock(RedisKeyPrefixConst.PRODUCT_CACHE + productId);
            RLock readLock = readWriteLock.readLock();
            readLock.lock(5,TimeUnit.SECONDS);
            try {
                product = productDao.create(product);
                if (product == null) {
                    // //读延期
                    redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
                    LOCAL_CACHE.put(RedisKeyPrefixConst.PRODUCT_CACHE + productId,product);
                    return null;
                }
                redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                        genProductCacheTimeout(), TimeUnit.SECONDS);

                LOCAL_CACHE.put(RedisKeyPrefixConst.PRODUCT_CACHE + productId,product);
            }finally {
                readLock.unlock();
            }
        } finally {
            lock.unlock();
        }

        return product;
    }

 // 从redis里获取数据  和本地缓存里获取
    private Product getProductFromRedisAndLoclCache(Long productId, Product product) {
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

        //从jvm本地缓存虎丘
        Object o = LOCAL_CACHE.get(productCacheKey);
        if (o != null) {
            return (Product) o;
        }

        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }
        return product;
    }


如果从本地读取缓存,那我们也需要维护本地缓存,本来 db 和redis数据一致性就够麻烦了,再多一层本地缓存,意味着系统复杂性又增加。
维护本地缓存,这里我们可以使用bin log去维护,延迟性不是很高,偶尔有一点点不一致,是可以接受的。

这种缓存需要注意的是

  • jvm本地cache 是需要同步更新所有的… 如果有一个没更新成功会产生脏数据,建议使用binl log订阅去更新.
  • 这种方案不能解决热点中实时热点的数据,可能需要配合大数据去实时计算监控热点数据…
  • 可能过一段时间就不是热点了,需要实施维护,另外jvm缓存空间是有限的,针对这种建议用另外一种针对热点的系统进行维护…

缓存穿透

上面解决了缓存击穿,缓存一致性问题,但是面对恶意攻击,如果说查一些数据我们缓存里没有,redis里也没有,我们的缓存就形同虚设。

缓存穿透是指查询一个根本不存在的数据, 缓存层和存储层都不会命中, 通常出于容错的考虑, 如果从存储 层查不到数据则不写入缓存层。 缓存穿透将导致不存在的数据每次请求都要到存储层去查询, 失去了缓存保护后端存储的意义。 造成缓存穿透的基本原因有两个:

第一, 自身业务代码或者数据出现问题。
第二, 一些恶意攻击、 爬虫等造成大量空命中。

面对(缓存穿透问题) 解决方案

  • 1 设置null值
  • 2 布隆过滤器

这里不考虑,双写一致,并发读写,大流量缓存构建以及实时性等问题

方案 1


    public static final Integer PRODUCT_CACHE_TIMEOUT = 60 * 60 * 24;
    public static final String EMPTY_CACHE = "{}";
    
//短时间内 null 缓存
    public Product get0_1(Long productId) throws InterruptedException {
        Product product = null;

        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }


        product = productDao.create(product);
        if (product == null) {
            // //读延期
            redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productId, EMPTY_CACHE, genProductCacheTimeout(), TimeUnit.SECONDS);
            return null;
        }
        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + product.getId(), JSON.toJSONString(product),
                genProductCacheTimeout(), TimeUnit.SECONDS);

        return product;
    }

方案 2

使用布隆过滤器,这里我用伪代码。

 public Product get0_2(Long productId) throws InterruptedException {
        Product product = null;
        RBloomFilter<Long> bloomFilter = bloomFilter();
        boolean contains = bloomFilter.contains(productId);

        if (!contains){
            //ToDo "非法的商品id 或者 从db查询"
            product = getProductFromDb(productId, product);
            if (product == null){
                throw new  RuntimeException("非法字符!");
            }
            return product;
        }

        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
        String productStr = redisUtil.get(productCacheKey);
        if (!StringUtils.isEmpty(productStr)) {
            if (EMPTY_CACHE.equals(productStr)) {
                // //读延期
                redisUtil.expire(productCacheKey, genEmptyCacheTimeout(), TimeUnit.SECONDS);
                return null;
            }
            product = JSON.parseObject(productStr, Product.class);
            redisUtil.expire(productCacheKey, genProductCacheTimeout(), TimeUnit.SECONDS); //读延期
        }

        return getProductFromDb(productId, product);

    }

布隆过滤器点击查看

     private RBloomFilter<Long> bloomFilter(){
        RBloomFilter<Long> bloomFilter = redisson.getBloomFilter("products:type");
        return bloomFilter;
    }

    //todo  布隆过滤器数据初始化,布隆过滤器不能删除数据,必须重新初始化
    @PostConstruct
    private RBloomFilter<Long> init(){
        RBloomFilter<Long> bloomFilter = bloomFilter();
        List<Product> products = Arrays.asList(
                new Product(1L, "iPhone 11"),
                new Product(2L, "iPhone 11 pro"),
                new Product(3L, "iPhone 11 pro max")
        );
        products.forEach(x->  bloomFilter.add(x.getId()));
        return bloomFilter;
    }

缓存雪崩

在使用缓存时,通常会对缓存设置过期时间,一方面目的是保持缓存与数据库数据的一致性,另一方面是减少冷缓存占用过多的内存空间。
但当缓存中大量热点缓存采用了相同的实效时间,就会导致缓存在某一个时刻同时实效,请求全部转发到数据库,从而导致数据库压力骤增,甚至宕机。从而形成一系列的连锁反应,造成系统崩溃等情况。

预防和解决缓存雪崩问题, 可以从以下几个方面进行着手。

  • 通常的解决方案是将key的过期时间后面加上一个随机数(比如随机1-5分钟),让key均匀的失效。

  • 考虑用队列或者锁的方式,保证缓存单线程写,但这种方案可能会影响并发量。

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

  • 双key策略,主key设置过期时间,备key不设置过期时间,当主key失效时,直接返回备key值。

  • 构建缓存高可用集群(针对缓存服务故障情况)。比如使用Redis Sentinel或Redis Cluster。

  • 当缓存雪崩发生时,服务熔断、限流、降级等措施保障。比如使用Sentinel或Hystrix限流降级组件。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/526991.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Linux常用命令——iconv命令

在线Linux命令查询工具 iconv 转换文件的编码方式 补充说明 iconv命令是用来转换文件的编码方式的&#xff0c;比如它可以将UTF8编码的转换成GB18030的编码&#xff0c;反过来也行。JDK中也提供了类似的工具native2ascii。Linux下的iconv开发库包括iconv_open,iconv_close,…

《程序员面试金典(第6版)》面试题 16.22. 兰顿蚂蚁(哈希映射,C++)

题目描述 一只蚂蚁坐在由白色和黑色方格构成的无限网格上。开始时&#xff0c;网格全白&#xff0c;蚂蚁面向右侧。每行走一步&#xff0c;蚂蚁执行以下操作。传送门 (1) 如果在白色方格上&#xff0c;则翻转方格的颜色&#xff0c;向右(顺时针)转 90 度&#xff0c;并向前移动…

【Vue2.0源码学习】虚拟DOM篇-Vue中的虚拟DOM

文章目录 1. 前言2. 虚拟DOM简介3. Vue中的虚拟DOM3.1 VNode类3.2 VNode的类型3.2.1 注释节点3.2.2 文本节点3.2.3 克隆节点3.2.4 元素节点3.2.5 组件节点3.2.6 函数式组件节点3.2.7 小结 3.3 VNode的作用 4. 总结 1. 前言 虚拟DOM&#xff0c;这个名词作为当下的前端开发人员…

Android Studio Flamingo (火烈鸟) 升级踩坑记录

由于想要验证Compose最新的debug特性&#xff0c;而我目前使用的版本&#xff08;Dolphin 小海豚&#xff09;不支持&#xff0c;查看官网说明需要最新版本&#xff0c;所以不得已进行了一下Android Studio版本升级&#xff0c;过程中遇到一些问题&#xff0c;本文仅做记录。&a…

FPGA驱动WM8731音频收发全网最细讲解 提供2套工程源码和技术支持

目录 1、前言2、WM8731音频解读3、vivado工程1介绍4、vivado工程2介绍5、上板调试验证6、资料获取 1、前言 本文用FPGA驱动WM8731音频芯片&#xff0c;实现音频相关的应用&#xff0c;适用于在校学生做毕业设计、研究生项目开发&#xff0c;也适用于在职工程师做项目开发&…

Ae 首选项:启动和修复

使用“首选项”里面的启动和修复 Start and Repair面板&#xff0c;可以解决 Ae 中的首选项设置问题&#xff0c;而无需更改、删除或者重新进行设置。 启动选项 Startup Options 启用主屏幕 Enable Home Screen 确定是否在启动 Ae 时显示主屏幕。 更改将在下次启动时有效。 显示…

element-plus 问题

对话框内部下拉框会在左上角 在对话框内打开下拉框后点击关闭按钮&#xff0c;尚未关闭的下拉框会在左上角出现&#xff08;或闪现&#xff09; 解决方案&#xff1a; popper-append-to-body 此方法失效&#xff0c;改用 :teleported"false" teleported&#xff1a;…

JDBC和数据库连接池

文章和代码已经归档至【Github仓库&#xff1a;https://github.com/timerring/java-tutorial 】或者公众号【AIShareLab】回复 java 也可获取。 文章目录 JDBC 概述基本介绍模拟JDBCJDBC 带来的好处 JDBC 快速入门JDBC 程序编写步骤JDBC 第一个程序 获取数据库连接5种方式方式1…

接入 GPT-4 的 AI 虚拟女友,一周狂挣 50 万!

公众号关注 “GitHubDaily” 设为 “星标”&#xff0c;每天带你逛 GitHub&#xff01; 随着 ChatGPT 的爆火&#xff0c;互联网上也衍生出不少令人直呼脑洞大开的 AI 应用。 最近&#xff0c;国外一位名为 Caryn Marjorie 的小姐姐搞了个骚操作&#xff0c;基于 GPT-4 调教出来…

Spring Cloud LoadBalancer是什么?

什么是Spring Cloud LoadBalancer Spring Cloud LoadBalancer是Spring Cloud官方自己提供的客户端负载均衡器, 用来替代 Ribbon。 Spring官方提供了两种负载均衡的客户端&#xff1a; RestTemplate RestTemplate是Spring提供的用于访问Rest服务的客户端&#xff0c;RestTempla…

30从零开始学Java之详解面向对象的7种创建方式

作者&#xff1a;孙玉昌&#xff0c;昵称【一一哥】&#xff0c;另外【壹壹哥】也是我哦 千锋教育高级教研员、CSDN博客专家、万粉博主、阿里云专家博主、掘金优质作者 前言 在上一篇文章中&#xff0c;壹哥给大家介绍了Java中的类及其特点、创建过程等内容&#xff0c;相信你…

【Nginx高级篇】Lua基础语法和OpenResty的安装

目录 一、前言 二、Lua基础语法 hello world 保留关键字 注释 变量 字符串 空值 布尔类型 作用域 控制语句 if-else for循环 函数 赋值 返回值 Table 数组 遍历 成员函数 三、openresty的安装 &#xff08;一&#xff09;预编译安装 &#xff08;二&…

VMware中Ubuntu拓展磁盘容量的两种方式 图形化方式命令行磁盘分区方式(亲测有效简单且详细)linux磁盘分区

文章目录 前言1. 软件设置扩容2. 容量查看3. 容量拓展实现3.1 图形化容量拓展分配3.2 磁盘命令行方式拓展容量3.2.1 确定磁盘挂载目录3.2.2 系统磁盘扩容 4. 分盘扩容TIPS&#xff1a;总结&#xff1a; 前言 在用VMware虚拟机的情况下&#xff0c;一开始分配的容量在使用过程中…

PMP项目管理-[第十二章]采购管理

采购管理知识体系&#xff1a; 规划采购管理&#xff1a; 实施采购&#xff1a; 控制采购&#xff1a; 12.1 规划采购管理 定义&#xff1a;记录项目采购决策、明确采购方法、识别潜在卖方的过程 作用&#xff1a;确定是否从项目外部获取货物或服务.如果是&#xff0c;则还要确…

循环结构程序设计

一、循环结构语句 C语言提供了三种循环语句&#xff08;for语句&#xff09;、while语句和do-while语句。 for语句&#xff1a; for(表达式1 &#xff1b; 表达式2 &#xff1b; 表达式3) {   循环体语句&#xff1b; } for语句的执行过程&#xff1a; 首先计算表达式1。判断…

【LED子系统】五、核心层详解(二)

个人主页&#xff1a;董哥聊技术 我是董哥&#xff0c;高级嵌入式软件开发工程师&#xff0c;从事嵌入式Linux驱动开发和系统开发&#xff0c;曾就职于世界500强公司&#xff01; 创作理念&#xff1a;专注分享高质量嵌入式文章&#xff0c;让大家读有所得&#xff01; 文章目录…

基于B/S架构、可替代付费商业软件的一站式量化交易平台

产品简介 这是一个面向程序员的量化交易软件&#xff0c;用于期货、股票、外汇、炒币等多种交易场景&#xff0c;实现自动交易。已对接了CTP接口&#xff08;国内期货&#xff09;、老虎证券接口&#xff08;美股港股&#xff09;。 功能特性&#xff1a; 一站式平台&#x…

Protell99SE祭文

Protell99SE祭文 大概是在21年前的今天&#xff0c;我和你结合在一起&#xff0c;陪伴走过无数的设计。 我的感觉&#xff0c;大概是在2021年吧&#xff0c;你逐渐离我远去。啊&#xff0c;Protel99SE时代一去不复返了。 我用了你21年&#xff0c;虽着AD软件的到来&#xff…

【C++】19.C++11

1.C11 auto 范围for 新容器 线程库列表初始化右值引用和移动语义 lambda表达式容器支持花括号列表初始化 本质是增加一个initializer_list的构造函数initializer_list支持花括号 2.列表初始化 #define _CRT_SECURE_NO_WARNINGS 1 #include <iostream> #include <ve…

​数字化转型升级之工业元宇宙与AIGC

月説小飞象交流会 生活就是&#xff0c;面对复杂&#xff0c;保持欢喜。心烦时&#xff0c;记住三句话&#xff1a;1、算了吧。2、没关系。3、会过去的。 内部交流│24期 数字化转型升级 工业元宇宙与AIGC data analysis ●●●● 分享人&#xff1a;李铁军 ‍ 现如今数字化不再…