分布式缓存问题

1 缓存失效问题

先来解决大并发读情况下的缓存失效问题;

1.1 缓存穿透

1.1.1 问题描述

  • 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中,将去查询数据库,但是数据库也无此记录,我们没有将这次查询的null 写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。
  • 在流量大时,可能DB 就挂掉了,要是有人利用不存在的key 频繁攻击我们的应用,这就是漏洞。

1.1.2 解决方案:

(1) 对空值缓存:如果一个查询返回的数据为空(不管是数据是否不存在),我们仍然把这个空结果(null)进行缓存,设置空结果的过期时间会很短,最长不超过五分钟。

(2) 设置可访问的名单(白名单):
使用bitmaps类型定义一个可以访问的名单,名单id作为bitmaps的偏移量,每次访问和bitmap里面的id进行比较,如果访问id不在bitmaps里面,进行拦截,不允许访问。

(3) 采用布隆过滤器:(布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数(哈希函数)。
布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。)
将所有可能存在的数据哈希到一个足够大的bitmaps中,一个一定不存在的数据会被 这个bitmaps拦截掉,从而避免了对底层存储系统的查询压力。

(4) 进行实时监控:当发现Redis的命中率开始急速降低,需要排查访问对象和访问的数据,和运维人员配合,可以设置黑名单限制服务

1.2 缓存雪崩

1.2.1 问题描述

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

1.2.2 解决方案:

(1) 构建多级缓存架构:nginx缓存 + redis缓存 +其他缓存(ehcache等)

(2) 使用锁或队列:
用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

(3) 设置过期标志更新缓存:
记录缓存数据是否过期(设置提前量),如果过期会触发通知另外的线程在后台去更新实际key的缓存。

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

1.3 缓存击穿

1.3.1 问题描述

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

1.3.2 解决方案

(1)预先设置热门数据:在redis高峰访问之前,把一些热门数据提前存入到redis里面,加大这些热门数据key的时长

(2)实时调整:现场监控哪些数据热门,实时调整key的过期时长

(3)使用加锁:(在获得锁的前后,都进行缓存查询,都查不到才进行数据库查询),在分布式情况下本地锁也有用哦,最好使用分布式锁。
<1> 就是在缓存失效的时候(判断拿出来的值为空),不是立即去load db。
<2> 先使用缓存工具的某些带成功操作返回值的操作(比如Redis的SETNX)去set一个mutex key
<3> 当操作返回成功时,再进行load db的操作,并回设缓存,最后删除mutex key;
<4> 当操作返回失败,证明有线程在load db,当前线程睡眠一段时间再重试整个get缓存的方法。

2 分布式锁解决方案

SET key value [EX seconds] [PX milliseconds] [NX|XX]
set product_lock 1 EX 2 NX
TTL product_lock


		
String uuid = UUID.randomUUID().toString();
Boolean lockFlag = redisTemplate.opsForValue().setIfAbsent("product_lock", uuid, 300, TimeUnit.SECONDS);
/* 此段代码加锁有问题:存在死锁问题
Boolean lockFlag = redisTemplate.opsForValue().setIfAbsent("product_lock", "1");
*/
if(lockFlag) {
    
    
	// redisTemplate.expire("product_lock", 30, TimeUnit.SECONDS);
	// TODO 执行业务逻辑
	/* 此段代码解锁有问题:存在死锁问题
	String lockValue = redisTemplate.opsForValue().get("product_lock");
	if(uuid.equals(lockValue)) {
		redisTemplate.delete("product_lock");
	}
	*/
	String script = "if redis.call('get',KEYS[1]) == ARGV[1] "
			+"then "
			+"	return redis.call('del',KEYS[1]) "
			+"else "
			+"	 return 0 "
			+"end ";
	Integer execute = redisTemplate.execute(new DefaultRedisScript<Integer>(script,Integer.class),Arrays.asList("product_lock"),uuid);
	// TODO
}

2.1 redisson

@Configuration
public class RedissonConfig {
    
    
	@Bean
	public RedissonClient redissonClient() {
    
    
		Config config = new Config();
		config.useSingleServer().setAddress("redis://192.168.6.6:6379").setPassword("Dky@Nqi2021");
		RedissonClient redisson = Redisson.create(config);
		return redisson;
	}
}
@Controller
public class MichaelController {
    
    
	@Autowired
	private RedissonClient redissonClient;

	@GetMapping("/hello")
	@ResponseBody
	public String hello() {
    
    
		// 1、获取一把锁,只要锁的名字一样,就是同一把锁
		RLock rLock = redissonClient.getLock("my-first-lock");
		/// 2、加锁
		rLock.lock();// 阻塞式等待(默认加的锁是30s时间)
		//1)锁的自动续期,如果业务超长,运行期间自动给锁续上新的30s。不用担心业务时间长,锁自动过期被删除。
		//2)加锁的业务只要运行完成,就不会给当前锁续期,即使不手动解锁,锁默认在30s以后会自动删除。
		try {
    
    
			System.out.println("加锁成功,执行业务..." + Thread.currentThread().getId());
			Thread.sleep(10000);// 睡10秒
		} catch (Exception e) {
    
    
			// TODO: handle exception
		} finally {
    
    
			// 3、解锁
			System.out.println("释放锁..." + Thread.currentThread().getId());
			rLock.unlock();
		}
		return "hello";
	}
}
==>同时执行两个请求,效果如下<==
// 加锁成功,执行业务...78
// 释放锁...78
// 加锁成功,执行业务...79
// 释放锁...79

猜你喜欢

转载自blog.csdn.net/Michael_lcf/article/details/122253041