Redis缓存三大问题

1 缓存穿透

1.1 问题描述

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

1.2 造成的原因

1.业务代码自身问题

2.恶意攻击。爬虫等等

1.3 解决方案

方案一：缓存空对象

public class NullValueResultDO implements Serializable{
   private static final long serialVersionUID = -6550539547145486005L;
}

public class UserManager {
     UserDAO userDAO;
     LocalCache localCache;
     public UserDO getUser(String userNick) {
          Object object = localCache.get(userNick);
          if(object != null) {
               if(object instanceof NullValueResultDO) {
                    return null;
               }
               return (UserDO)object;
          } else {
               User user = userDAO.getUser(userNick);
               if(user != null) {
                    localCache.put(userNick,user);
               } else {
                    localCache.put(userNick, new NullValueResultDO());
               }
               return user;
          }
     }          
}

方案二：布隆过滤器

将已存在的对象id列表缓存到布隆过滤其中并设置匹配率，当接收到查询对象的请求时，首先查询的对象是否在布隆过滤器其中，返回不存在时，则不必再去查询数据库。

1）Google布隆过滤器

基于JVM内存的一种布隆过滤器

缺点：

重启即失效

本地内存无法用在分布式场景

不支持大数据量存储

2）Redis布隆过滤器

可扩展性Bloom过滤器：一旦Bloom过滤器达到容量，就会在其上创建一个新的过滤器

不存在重启即失效或者定时任务维护的成本：基于Google实现的布隆过滤器需要启动之后初始化布隆过滤器

缺点：需要网络IO，性能比Google布隆过滤器低

2 缓存击穿

2.1 问题描述

缓存击穿是指在高并发情境下，缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

2.2 造成的原因

使用缓存，如果获取不到，才会去数据库里获取。但是如果是热点 key，访问量非常的大，数据库在重建缓存的时候，会出现很多线程同时重建的情况。因为高并发导致的大量热点的 key 在重建还没完成的时候，不断被重建缓存的过程，由于大量线程都去做重建缓存工作，导致服务器拖慢的情况。

2.3 解决方案

互斥锁

第一次获取缓存的时候，加一个锁，然后查询数据库，接着是重建缓存。这个时候，另外一个请求又过来获取缓存，发现有个锁，这个时候就去等待，之后都是一次等待的过程，直到重建完成以后，锁解除后再次获取缓存命中。

互斥锁的优点是思路非常简单，具有一致性，但是互斥锁也有一定的问题，就是大量线程在等待的问题。存在死锁的可能性。

互斥锁的实现根据项目的场景可分为分布式锁和java普通锁。

3 缓存雪崩

3.1 问题描述

缓存雪崩是指机器宕机或在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，数据库瞬时压力过重雪崩。

3.2 造成的原因

过多的缓存数据同时失效同时访问数据库造成数据库压力突然变大。

3.3 解决方案

1：分布式锁

减少同一时间对数据库的并发访问量

2：部署高可用集群方案

3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。