高并发下缓存失效问题--（缓存穿透，缓存雪崩，缓存击穿）
1 缓存穿透
指查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义
1.1 风险
利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃
1.2 解决
null结果缓存，并加入短暂过期时间
set(String key, String value, long timeout, TimeUnit unit)2 缓存雪崩
缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
2. 1 解决
原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
3 缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。
如果这个key在大量请求同时进来前正好失效，那么所有对这个key的数据查询都落到db，我们称为缓存击穿。
3.1 解决
加锁：大量并发只让一个去查，其他人等待，查到以后释放锁，其他人获取到锁，先查缓存，就会有数据，不用去db
//加锁
//只要是同一把锁，就能锁住需要这个锁的所有线程
//1、synchronized(this): SpringBoot所有的组件在容器中都是单例的。
synchronized(this){
//得到锁以后,我们应该再去缓存中确定一次,如果没有才需要继续查询
}4 分布式锁
4.1 分布式下如何加锁：
4.2 本地锁在分布式下的问题：
因此，在加本地锁后，当用户查询数据结束前，要将结果再查询放入到缓存中 ，这样可以解决穿透问题。
分布式下，本地锁只能锁住自己，不能锁住别人，在并发请求下会导致多个查询数据库。
4.3 分布式锁演进
基本原理：
我们可以同时去一个地方“占坑”，如果占到，就执行逻辑。否则就必须等待，直到释放锁。
“占坑”可以去redis，可以去数据库，可以去任何大家都能访问的地方。
等待可以自旋的方式。
阶段一：
//1、占分布式锁。去redis占坑
redisTemplate.opsForValue().setIfAbsent(String key, String value);
if(lock){
//加锁成功... 执行业务
//删除锁
redisTemplate.delete(String key);
//返回方法
}else{
//加锁失败...重试。synchronized()
//休眠100ms重试
//返回（自旋的方式）
}示例代码：
阶段二：
//1、占分布式锁。去redis占坑
redisTemplate.opsForValue().setIfAbsent(String key, String value);
if(lock){
//加锁成功... 执行业务
//2、设置过期时间
redisTemplate.expire(String Key, lopg timeout, TimeUnit unit);
//删除锁
redisTemplate.delete(String key);
//返回方法
}else{
//加锁失败...重试。synchronized()
//休眠100ms重试
//返回（自旋的方式）
}示例代码：
阶段三：
//1、占分布式锁。去redis占坑
redisTemplate.opsForValue().setIfAbsent(String key, String value, long timeout, TimeUnit unit);
if(lock){
//加锁成功... 执行业务
//2、设置过期时间，必须和加锁是同步的，原子的
redisTemplate.expire(String Key, lopg timeout, TimeUnit unit);
//删除锁
redisTemplate.delete(String key);
//返回方法
}else{
//加锁失败...重试。synchronized()
//休眠100ms重试
//返回（自旋的方式）
}示例代码：
阶段四：
示例代码：
阶段五-最终形态：
示例代码：
进一步优化：
try{}finally{} 无论业务是执行还是崩溃，最终还是全部进行解锁。
