2022-03-18 /2022/03/18/2022-03-18-redis高并发场景问题解析/ 99+ 26 分钟 3.8 k

2022-03-18—Redis高并发场景问题解析

Redis高并发场景问题分析：缓存失效、缓存穿透、缓存数据不一致、缓存雪崩

1、缓存失效

缓存失效也叫缓存击穿，本人更喜欢叫缓存失效。

1.1、业务场景：

比如商家可以批量导入商品，那么这些商品的缓存数据就是同一个失效时间，失效后，又进行这些数据的查询，就会造成缓存失效（击穿），请求直接到达数据库，有可能导致数据挂掉。

1.2、导致结果：

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。

1.3、解决方案：

1、查询get商品时，给商品数据加随机失效时间，防止了数据的批量失效;

2、批量添加商品缓存时，每样商品添加随机的失效时间。
伪代码写法：

public String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        //设置一个过期时间(300到600之间的一个随机数)
        int expireTime = new Random().nextInt(300)  + 300;
        if (storageValue == null) {
            cache.expire(key, expireTime);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

图片记忆：

缓存失效

2、缓存穿透

2.1 、业务场景：

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

2.1.1 、造成原因：

造成缓存穿透的基本原因有两个：
第一，自身业务代码或者数据出现问题。
第二，一些恶意攻击、爬虫等造成大量空命中。

2.1 、导致结果：

可能导致后端存储架构坍塌。
缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。

2.2 、解决方案：

2.2.1、缓存空对象。

如果后端查不到该产品数据，就放一个空的商品缓存到redis，并给空缓存设置过期时间（这个很重要，防止以后有了这个产品数据，缓存还是空的问题）
伪代码如下：

public String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);
    // 缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        // 如果存储数据为空， 需要设置一个过期时间(300秒)
        if (storageValue == null) {
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    } else {
        // 缓存非空
        return cacheValue;
    }
}

2.2.2、使用布隆过滤器。

对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。

步隆过滤器

布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。

向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。

向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。

这种方法适用于数据命中不高、数据相对固定、实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用很少。

可以用redisson实现布隆过滤器，引入依赖：

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.8</version>
</dependency>

实例代码：

package com.redisson.filter;

import org.redisson.Redisson;
import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

/**
 * 布隆过滤器示例
 * @author ellisonpei
 */
public class RedissonBloomFilter {

    public static void main(String[] args) {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://119.yy.xx.104:6379").setPassword("peixxsxss");
        //构造Redisson
        RedissonClient redisson = Redisson.create(config);

        RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
        //初始化布隆过滤器：预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小
        // 初步计算，如果布隆过滤器设置 100亿的容量，占磁盘大小也才 9个G,
        // 缺点：布隆过滤器不允许修改，后台需要定期初始化布隆过滤器
        bloomFilter.tryInit(100000L,0.03);
        //将数据插入到布隆过滤器中
        bloomFilter.add("ell1");
        bloomFilter.add("pei");

        //判断下面号码是否在布隆过滤器中
        System.out.println(bloomFilter.contains("boll"));//false
        System.out.println(bloomFilter.contains("yan"));//false
        System.out.println(bloomFilter.contains("ell1"));//true
    }
}

使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放，布隆过滤器缓存过滤伪代码：

@Service
public class ProductService {
    @Autowired
    private RedissonClient redissonClient;

    private RBloomFilter<String> bloomFilter = null;

    @PostConstruct
    private void init(){
        // 初始化布隆过滤器
        bloomFilter = redissonClient.getBloomFilter("nameList");
        //初始化布隆过滤器：预计元素为100000000L,误差率为3%
        bloomFilter.tryInit(100000000L,0.03);
        // 从数据库查询出来的商品 list
        String[] productIdList = {"1","2","3","4"};
        //把所有数据存入布隆过滤器
        for (String s : productIdList) {
            bloomFilter.add(s);
        }
    }
}

注意：布隆过滤器不能删除数据，如果要删除得重新初始化数据。
图片记忆：

缓存穿透

3、热点数据缓存key重建问题

3.1 、业务场景：

比如直播带货，主播经常会带一些冷门的商品，往往这些商品在缓存中已失效，不存在了。直播期间会有百万千万粉丝，下单，造成直接去数据库查询，请求积压，造成后端负载加大，甚至可能会让应用崩溃。
比如秒杀活动、热点微博、热评，某件商品被数万次点击浏览或购买时，就会造成热点问题
被大量发布、浏览的热点新闻、热点评论等读多写少场景也会产生热点问题
3.1.1 、热点数据缓存key的危害：

热点数据缓存key的危害

流量过于集中，突破物理网卡的极限
请求过多，缓存分片服务被打垮
穿透DB

当某热点Key请求在某一主机上超过该主机网卡上限时，由于流量过度集中，导致服务器中其它服务无法正常进行
=》
热点过于集中，热点Key缓存过多，超过目前的缓存容量，就会导致缓存分片服务被打垮
=》
缓存服务崩溃，此时再有请求产生，会缓存到后台DB，导致缓存穿透，进一步还会导致缓存雪崩。

3.1.2 、造成原因及结果：

开发人员使用“缓存+过期时间”的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：
当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。

重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。
在缓存失效的瞬间，有大量线程来重建缓存， 造成后端负载加大，甚至可能会让应用崩溃。
要解决这个问题主要就是要避免大量线程同时重建缓存。

3.2 、解决方案：

我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

3.2.1 、利用redis的setnx来限制

伪代码如下：

public String get(String key) {
    // 从Redis中获取数据
    String value = redis.get(key);
    // 如果value为空， 则开始重构缓存
    if (value == null) {
        // 只允许一个线程重建缓存， 使用nx， 并设置过期时间ex
        String mutexKey = "mutext:key:" + key;
        if (redis.set(mutexKey, "1", "ex 180", "nx")) {
             // 从数据源获取数据
            value = db.get(key);
            // 回写Redis， 并设置过期时间
            redis.setex(key, timeout, value);
            // 删除key_mutex
            redis.delete(mutexKey);
        }// 其他线程休息50毫秒后重试
        else {
            Thread.sleep(50);
            get(key);
        }
    }
    return value;
}

3.2.12、利用分布式锁来解决

伪代码如下：

public Product get(Long productId) {
        Product product = null;
        String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

        //从缓存里查数据
        product = getProductFromCache(productCacheKey);
        if (product != null) {
            return product;
        }

        //加分布式锁解决热点缓存并发重建问题
        RLock hotCreateCacheLock = redisson.getLock(LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + productId);
        hotCreateCacheLock.lock();
        // 这个优化谨慎使用，防止超时导致的大规模并发重建问题
        // hotCreateCacheLock.tryLock(1, TimeUnit.SECONDS);
        try {
            product = getProductFromCache(productCacheKey);
            if (product != null) {
                return product;
            }

            product = getProductFromDb(productCacheKey, productId);

        } finally {
            hotCreateCacheLock.unlock();
        }

        return product;
    }

图片记忆：

热点数据key重建

4、缓存与数据库数据不一致

4.1、业务场景

在大并发下，同时操作数据库与缓存会存在数据不一致性问题。

4.2、场景分析

不一致情况有两种，一是双写并发不一致，二是读写并发不一致

1、双写并发不一致

双写并发不一致

2、读写并发不一致

读写并发不一致

4.3 、解决方案

1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
3、如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。

4.4 、总结

以上针对的都是读多写少的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。当然，如果数据库抗不住压力，还可以把缓存作为数据读写的主存储，异步将数据同步到数据库，数据库只是作为数据的备份。

放入缓存的数据应该是对实时性、一致性要求不是很高的数据。切记不要为了用缓存，同时又要保证绝对的一致性做大量的过度设计和控制，增加系统复杂性！

图片记忆：

5、缓存雪崩

5.1 、业务场景：

超级热点事件（比如xx逃税）此时会有大量的请求（上亿）来到redis数据库，请求量过大，导致redis宕机，致使所有请求全部打向后端数据库。缓存层支撑不住或宕掉后，流量会像奔逃的野牛一样，打向后端存储层。

5.2 、后果：

Redis缓存撑不住，宕机，缓存层整体挂掉，请求直达数据库，严重的话，导致MySQL宕机。

5.3 、解决方案：

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

1）保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
2）依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
3）提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

图片记忆：

缓存雪崩

2022-03-18—Redis高并发场景问题解析

https://peialan.github.io/2022/03/18/2022-03-18-redis高并发场景问题解析/

作者

EllisonPei

发布于

2022-03-18

更新于

2022-08-10

2022-03-18—Redis高并发场景问题解析

1、缓存失效

1.1、业务场景：

1.2、导致结果：

1.3、解决方案：

2、缓存穿透

2.1 、业务场景：

2.1.1 、造成原因：

2.1 、导致结果：

2.2 、解决方案：

2.2.1、缓存空对象。

2.2.2、使用布隆过滤器。

3、热点数据缓存key重建问题

3.1 、业务场景：

3.1.1 、热点数据缓存key的危害：

3.1.2 、造成原因及结果：

3.2 、解决方案：

3.2.1 、利用redis的setnx来限制

3.2.12、利用分布式锁来解决

4、缓存与数据库数据不一致

4.1、业务场景

4.2、场景分析

4.3 、解决方案

4.4 、总结

5、缓存雪崩

5.1 、业务场景：

5.2 、后果：

5.3 、解决方案：

作者

发布于

更新于

许可协议

喜欢这篇文章？打赏一下作者吧

目录

链接

最新评论

最新文章

分类

归档

标签

订阅更新