关于高并发下的缓存

高并发下缓存问题

• 缓存穿透：指查询一个不存在的数据，由于缓存不命中，将去查询数据库，但是数据库也没记录，并且没有将这次查询的null写入缓存，这将导致整个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义

• 布隆过滤器
  //ToDo
  可以利用每个请求更换不同id继续缓存穿透，也将导致数据库瞬时压力增大

• 风险：利用不存在的数据进行攻击，多并发下数据库瞬时压力增大，最终导致数据库崩溃

• 解决方案：null结果缓存，并加入短暂过期时间

• 缓存雪崩：指在我们设置key时采用了相同的过期时间，导致缓存在某一时刻同时失效，如果失效的时刻大量并发过来，这将导致数据库压力过而雪崩。

• 解决方案：原有的失效时间基础上增加一个随机值，这样重复率就会降低。

• 缓存击穿：对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“”热点“”的数据。如果这个key在大量请求同时进来前正好失效，那么数据库压力将瞬间增大从而导致崩溃

• 解决方案：加锁

• 大量并发只让一个线程去查，查完之后将“”热点“”数据加入缓存，其他线程等待，查到以后释放锁，之后其他线程获取到锁后，将优先查缓存而不用去查数据库。

• 缓存一致性

• 保证最终一致性的前提是缓存数据有过期时间
  1 双写模式：更改数据库的同时更改缓存
  2 失效模式：更改数据库的同时删除缓存，下次访问缓存时更新缓存

• 这两种策略都会有脏数据的问题，即数据库数据与缓存不一致。对于经常需要写，数据的一致性要求高的，不应该放到缓存里，而应该直接读数据。

• 如果怕出现脏数据的情况，可以加个读写锁，不过这会导致写的时候多线程效率降低

• canal：阿里开发的一个中间件

系统最终采用的一致性解决方案：
1、 缓存的所有数据都有过期时间，数据过期下一次查询触发主动更新
2、 读写数据的时候，加上分布式的读写锁，适用范围为写少读多的情况

SpingCache:Spring为缓存提供的统一接口，声明了两个接口
SpringCacheManage:统一不同的缓存，管理不同的缓存
SpringCache
整合springCache：

1. 引入依赖

2. `
   org.springframework.boot
   spring-boot-starter-cache

3. 写配置：

4. 自动配置了哪些
   CacheAutoConfigration会导入redisCacheConfigration

5. 配置使用redsi作为缓存

6. ` cache:
   type: redis

设置存活时间
redis:
time-to-live: 3600000
默认使用前缀
如果指定了前缀就用我们指定的 如果没有就用缓存的名字作为前缀
key-prefix: CACHE_
是否缓存空值
cache-null-values: true
cache-names:

测试使用缓存

1. 开启缓存功能： @EnableCaching

2. 使用注解测试

3. 在方法上标注@Cacheable

   • @Cacheable: 表示将此方法使用的结果放入缓存，并且缓存中没有才触发方法的执行后将结果放入缓存，缓存中已经有了就不触发方法的执行

     默认情况下

   当前方法的结果需要缓存 并指定缓存名字
   缓存的value值 默认使用jdk序列化 推荐使用json序列化 可以在多个语言中使用
   默认ttl时间 -1
   key: 里面默认会解析表达式， 自定义字符串用 " ‘要输入的文字’ "这种形式

   希望自定义的内容：

   •  指定生成缓存使用的key
     

   •  指