redis问题解决方案(三)

缓存穿透

 缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”
 的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
  
也就是说，每次发起id为数据库不存在的值时，都是连接数据库查询数据而非缓存获取，
而且查询结果为空，并会将空值写入缓存中。这样不但会加重数据库负担，而且还会消耗
系统资源。所以应在代码中对这种无意义的数据进行特殊处理。

缓存穿透(redis--mysql):指查询一个一定不存在的数据,
由于缓存不命中,并且出于容错考虑,如果
从存储层查不到数据则不写入缓存,这将导致
这个不存在的数据每次请求都要到存储层区
查询,失去了缓存的意义.

原因:
  1.业务代码自身问题
  2.恶意攻击

危害:
   对底层数据源压力大,有些数据源不具备高并发性.例如mysql一般来说单台
   能够扛1000QPS就已经很不错了

解决方案:
1.缓存空对象

2.布隆过滤器(谷歌提供的或者根据redis自己实现)

缓存击穿

缓存击穿是在高并发的条件下读取缓存数据，多用户同时请求同一个缓存数据，如果缓存中没有这条数据，那么这些用户又会同时去数据库中查询这条数据，浪费了系统资源，有
悖于缓存数据的初衷，严重的话可能会造成服务器宕机的风险。

解决方法有两种:
 1）.使用同步锁 synchronized 关键字，修饰在获取缓存的方法里面，保证在多用户同
 时请求条件下，只有第一个进入的线程去判断是否要查询数据库并存入缓存，其他线程只
 需在第一个线程结束后，从缓存中读取数据即可，无需再查询数据库。
 下面的代码是对缓存穿透的再次优化，加入 线程同步锁 以及 双重检查锁 。
 双重检查锁:1.避免当缓存数据 没有失效 时，其他线程排队等待。
          2.当第一个线程从数据库中获取到数据并存入缓存中时，其他线程直接从缓存获取数据即可。

2) .第二种是不设置缓存时间，由后台创建定时任务去维护这部分缓存数据。这种方法请求时直接从缓存中获取数据，无需再判断是否从数据库中获取，定时任务也可在请求较少的时间段分批更新缓存数据。

缓存雪崩

缓存雪崩是指在设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，导致所有的查询都落在数据库上，造成了缓存雪崩。

解决方案:
1）在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key
只允许一个线程查询数据和写缓存，其他线程等待。
2）可以通过缓存reload机制，预先去更新缓存，在即将发生大并发访问前手动触发加载
缓存。
3）不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
4）做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问
A2，A1缓存失效时间设置为短期，A2设置为长期。