Redis缓存问题优化

最新推荐文章于 2025-06-24 22:55:51 发布

原创最新推荐文章于 2025-06-24 22:55:51 发布 · 321 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #分布式

redis 专栏收录该内容

8 篇文章

订阅专栏

文章目录

- 缓存设计

缓存设计

缓存穿透

缓存穿透通常指，查询一下存储层（数据库）中不存在的数据，因为查询不到数据，所以一般来说不会将数据存放在缓存中，如果有人恶意针对性进行大量请求，那么就会直接穿透缓存直接攻击数据库，会造成数据库压力过大从而崩溃
造成缓存穿透的基本原因有两个：
第一，自身业务代码或者数据出现问题。
第二，一些恶意攻击、爬虫等造成大量空命中。

缓存空对象（伪代码）

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;
	}
}

布隆过滤器

对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。
这样就可以，当它说存在的时候，去缓存中拿，缓存中没有则去存储层获取
在这里插入图片描述

布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数运算，所谓的无偏就是把hash值算的比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash值运算，算得一个整数索引值然后对位数组长度进行取模运算得到一个位置（因为取模所以百分百会小等于数组长度），每个 hash 函数都会算得一个不同的位置。再把个个算出结果的值，在位数组的这几个位置都置为 1 就完成了 add 操作作。
这也很好证明了，当布隆过滤器说某个值存在时，它不一定存在，当说它不存在时，这个值一定不存在
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。这种方法适用于数据访问命中不高、数据相对固定、实时性低（通常是数据集较大）的应用场景，布隆过滤器代码维护较为复杂，但是缓存空间占用很少。
使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放，
注意：布隆过滤器不能删除数据，如果要删除得重新初始化数据。

<dependency>
   <groupId>org.redisson</groupId>
   <artifactId>redisson</artifactId>
   <version>3.6.5</version>
</dependency>
//伪代码
public static void main(String[] args) {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        //构造Redisson
        RedissonClient redisson = Redisson.create(config);

        RBloomFilter<String> bloomFilter = redisson.getBloomFilter("userIdList");
        //初始化布隆过滤器：预计元素为100000000L(所有需要存放的数量,并不是位数组数量.位数组数量会根据这些参数进行计算出来),误差率为3%,根据这两个参数会计算出底层的bit数组大小
        bloomFilter.tryInit(100000000L,0.03);
        //将zhuge插入到布隆过滤器中
        bloomFilter.add("10004");

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

//使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放，布隆过滤器缓存过滤伪代码：
//初始化布隆过滤器
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("userIdList");
//初始化布隆过滤器：预计元素为100000000L,误差率为3%
bloomFilter.tryInit(100000000L,0.03);
        
//把所有数据存入布隆过滤器
void init(){
    for (String key: keys) {
        bloomFilter.put(key);
    }
}

String get(String key) {
    // 从布隆过滤器这一级缓存判断下key是否存在
    Boolean exist = bloomFilter.contains(key);
    if(!exist){
        return "";
    }
    // 从缓存中获取数据
    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;
    }
}

缓存失效(击穿)

当为批量热点数据设置同一过期时间的时候，如果正好这些数据到了过期时间从缓存中失效的时候，大量数据直接透过缓存直接到达数据库，由于缓存失效导致击穿缓存导致的问题，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间（可以加个随机数来规避这种情况）

批量数据定时失效时间错开设置

//设置一个过期时间(300到600之间的一个随机数)
int expireTime = new Random().nextInt(300) + 300;

缓存雪崩

顾名思义缓存雪崩就是说白了,缓存层顶不住大量高并发请求而崩溃,由于缓存崩溃,导致后台一系列服务崩溃雪崩了
由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务(比如超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降)，于是大量请求都会打到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。
预防和解决缓存雪崩问题，可以从以下三个方面进行着手

保证缓存层服务高可用性

比如使用Redis Sentinel或Redis Cluster高可用集群架构可以很好保证防止缓存崩溃情况,前面有说如何搭建

为后端限流熔断并降级

依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
1.服务降级
当出现大量请求阻塞缓存访问的时候,可以通过超时时间,进行判断,让一些非核心数据请求比如商品属性,用户自己的基本信息,等非核心数据暂停从缓存中获取数据,而是直接返回预定义的默认降级信息(默认信息)、空值或是错误提示信息等,降低缓存层压力,核心数据仍然继续访问缓存,从缓存中获取核心数据,比如商品库存等,缓存不存在则访问数据库

提前预演

在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

热点缓存key重建优化

1.冷门数据变热门
所有数据是不可能都存放在缓存中,一些冷门数据消息等,但是如果当这些冷门数据,突然间上热门了,那么这个时候,由于没有缓存层帮忙承载大量并发请求的时候,所有数据打到存储层这个时候极有可能发送服务器宕机
2.热门数据缓存突然失效,需要重建优化
重建缓存是需要时间的,在这个过程中,大量请求高并发,会出现致命问题
我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。
示例伪代码：

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;
}

缓存数据库双写不一致

在高并发的情况下,同时操作数据库与缓存会存在双写不一致的情况

双写不一致

在这里插入图片描述
采取写删读写的话,可以解决双写不一致问题,但是会出现,读写并发不一致的情况

读写不一致

在这里插入图片描述
这里出现了读写不一致的情况,数据库中数据是stock=6,缓存中stock=10,只是概率性比较小就是了

解决方案：

1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。即使出现缓存数据库不一致,但是并不是啥核心数据,如果能容忍允许出现不一致情况,可以考虑这种方式
3、如果不能容忍缓存数据不一致，可以通过加读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。(这样子缓存的性能肯定有所下降,有点得不偿失)
读写要加锁是因为,如果在多线程情况下,读写不加锁的话,那么有可能会导致读的值,还未做了一些列操作之后,还未修改缓存的值,的过程中,写操作已经提前把值改变了,导致读的值是旧数据,所有读写要加锁,或者可以用版本号乐观锁来处理
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。
在这里插入图片描述