分布式锁

1：锁的时序问题

其中标红的要在一个逻辑中处理 

2.缓存穿透

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

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

解决:null结果缓存，并加入短暂过期时间

3.缓存雪崩

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

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

4.缓存击穿

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

解决：加锁

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

分布式锁设计:

String token  = UUID.randomUUID().toString();

Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock",uuid,300,TimeUnit.SECONDS);

if(lock){

//执行业务逻辑，从数据库中获取数据

String script = "if redis.call('get',KEYS[1]) ==ARVG[1] then return redis.call('del',KEYS[1])";

long lock1 = redisTemplate.execute(new DefaultRedisScript<Long>(script,Long.class),"lock",uuid);

return 数据；

}eles{

//加锁失败，重试

//方法调方法本身

}