高并发下缓存失效的问题

最新推荐文章于 2022-04-01 21:19:12 发布

漂泊_43458650

最新推荐文章于 2022-04-01 21:19:12 发布

阅读量193

点赞数 2

分类专栏： Redis 文章标签： redis 数据库 nosql java 缓存

本文链接：https://blog.csdn.net/qq_43458650/article/details/115457764

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文详细介绍了缓存系统中的三大问题：缓存穿透、缓存雪崩和缓存击穿。针对这些问题，提出了相应的解决方案。缓存穿透通过缓存null值并设置短暂过期时间来避免；缓存雪崩通过为每个缓存设置不同的过期时间减少集体失效；缓存击穿则采用加锁策略确保高并发下仅查询一次数据库。同时，文章还展示了如何优化代码以避免锁的时序问题，确保多线程环境下的正确性。

摘要由CSDN通过智能技术生成

1、缓存穿透

1）缓存穿透

只查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

2）风险

利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃。

3）解决

null结果缓存，并加入短暂过期时间。

2、缓存雪崩

1）缓存雪崩

缓存雪崩是指我们在设置缓存时key采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

2）解决

原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效事件。

3、缓存击穿

1）缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发的访问，是一种非常“热点”的数据
如果这个key在大量请求同时进来前正好失效，那么所有对这个key的数据查询都落到DB，我们称为缓存击穿

2）解决

加锁

大量并发只让一个去查，其他人等待，查到以后释放锁，其他人获取到锁，先查缓存就会有数据，不用去DB查。

public Map<String, List<Catalog2Vo>> getCategoryMap() {
        ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)) {
            System.out.println("缓存不命中，准备查询数据库。。。");
            Map<String, List<Catalog2Vo>> categoriesDb = getCategoriesDb();
            String toJSONString = JSON.toJSONString(categoriesDb);
            ops.set("catalogJson",toJSONString);
            return categoriesDb;
        }
        System.out.println("缓存命中。。。。");
        Map<String, List<Catalog2Vo>> listMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {});
        return listMap;
    }

 private synchronized Map<String, List<Catalog2Vo>> getCategoriesDb() {
        String catalogJson = stringRedisTemplate.opsForValue().get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)) {
            System.out.println("查询了数据库");
      		。。。。。
            return listMap;
        }else {
            Map<String, List<Catalog2Vo>> listMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {});
            return listMap;
        }
    }

3）锁的时序问题

在上述方法中，我们将业务逻辑中的确认缓存没有和查数据库放到了锁里，但是最终控制台却打印了两次查询了数据库。这是因为在将结果放入缓存的这段时间里，有其他线程确认缓存没有，又再次查询了数据库，因此我们要将结果放入缓存也进行加锁

优化代码逻辑后

public Map<String, List<Catalog2Vo>> getCategoryMap() {
    ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)) {
            System.out.println("缓存不命中，准备查询数据库。。。");
            synchronized (this) {
                String synCatalogJson = stringRedisTemplate.opsForValue().get("catalogJson");
                if (StringUtils.isEmpty(synCatalogJson)) {
                    Map<String, List<Catalog2Vo>> categoriesDb= getCategoriesDb();
                    String toJSONString = JSON.toJSONString(categoriesDb);
                    ops.set("catalogJson", toJSONString);
                    return categoriesDb;
                }else {
                    Map<String, List<Catalog2Vo>> listMap = JSON.parseObject(synCatalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {});
                    return listMap;
                }
            }
        }
        System.out.println("缓存命中。。。。");
        Map<String, List<Catalog2Vo>> listMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {});
        return listMap;
}