关于redis:缓存

即时性、数据一致性要求不高的
访问量大且更新频率不高的数据（读多，写少）
举例：电商利用，商品分类，商品列表等适宜缓存并加一个生效工夫（依据数据更新频率来定），后盾如果公布一个商品，买家须要 5 分钟能力看到新的商品个别还是能够承受的

缓存穿透
查问一个不存在的数据，因为缓存是不命中的，将去查询数据库，然而数据库也无此记录，咱们没有将这个此查问的 null 写入缓存，这将导致这个不存在的数据每次申请都到存储层查问，失去了缓存的意义。
危险：利用不存在的数据进行攻打，数据库刹时压力增大，最终导致解体
解决：null 后果缓存，并退出短暂过期工夫
缓存雪崩
指在咱们设置缓存时 key 采纳了雷同的过期工夫，导致缓存在某一时刻同时生效，申请全副转发到 DB，DB 刹时压力过重雪崩。
解决：原有生效工夫的根底上减少一个随机值，比方 1 - 5 分钟随机，这样没有一个缓存的过期工夫的反复率就会升高，就很难引发个体生效事件。
缓存击穿
对于设置过期工夫的 key，如果这些 key 可能会在某些工夫点被高并发地拜访，是一种十分 ” 热点 ” 的数据。
如果这个 key 在大量申请同时进来前正好生效，那么所有对这个 key 的数据查问都落到 DB，咱们称为缓存击穿。
解决：加锁，大量并发只让一个去查，其他人期待，查到后开释锁，其他人获取到锁，先查缓存，就会有数据，不必去 DB

 只有是同一把锁，就能锁住须要这把锁的所有线程，

1. synchronized(this)，JUC(lock)

SpringBoot 所有的组件在容器中都是单例的，一个服务一个容器，一个容器一个实例，

每个 this 是不同的锁，

基本原理： 能够去一个中央占坑，占到就执行逻辑，否则期待，直到开释锁，” 占坑 ” 能够去 redis，能够去数据库，能够去任何大家都能拜访到的中央，期待能够自旋的形式。
问题

setnx 占好了位，业务异样或者程序在页面过程中宕机，没有执行删除锁逻辑，就造成了死锁，能够通过设置锁的主动过期，即便没有删除，会主动删除，设置过期和加锁要原子操作
如果业务工夫长，锁本人过期了，咱们间接删除，有可能把他人正在持有的锁删除了，占锁的时候指定 uuid，每个人匹配本人的锁才删除。删除之前判断是否是本人的
```
 String lockValue = stringRedisTemplate.opsForValue().get("lock");
 if (uuid.equals(lockValue)) {stringRedisTemplate.delete("lock");
 }
```

但这样还是有问题，从 redis 取出值，返回的路上，redis 过期了，别的线程加锁胜利，这时判断为 true，删除就删除了别的线程的锁，所以获取，判断，删除要是原子操作，通过 lua 脚本来实现。

Redisson

无论双写还是生效模式，都会导致缓存不统一问题，即多个实例同时更新会出事，怎么办？

总结

一、缓存的应用