0x01：缓存的三大问题

• 缓存穿透：访问不存在的数据（Bloom Filter，缓存空对象）
• 缓存击穿：热点 key 重建过程中，造成的缓存问题（分布式锁）
• 缓存雪崩：Redis 宕机，或缓存批量失效（高可用集群，错开缓存失效时间）

缓存粒度控制

通俗来讲，缓存粒度问题就是我们在使用缓存时，是将所有数据缓存还是缓存部分数据？

缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成很多无用空间的浪费，可能会造成网络带宽的浪费，可能会造成代码通用性较差等情况，必须学会综合数据通用性、空间占用比、代码维护性 三点评估取舍因素权衡使用。

0x02：缓存穿透问题，访问不存在的数据

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

可能造成原因

• 业务代码自身问题
• 恶意攻击。爬虫等等

危害

对底层数据源压力过大，有些底层数据源不具备高并发性。 例如 MySQL 一般来说单台能够扛1000 QPS 就已经很不错了

解决方案

缓存空对象

缺点：恶意攻击的清空下，会产生大量的空对象，数据库压力仍然存在，治标不治本

public class NullValueResultDO implements Serializable {
}

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;
          }
     }          
}

布隆过滤器

• Google 布隆过滤器的缺点

• 不需要网络 IO，效率高，维护成本低
• 缺点：基于JVM内存的一种布隆过滤器，重启即失效，本地内存无法用在分布式场景，不支持大数据量存储

• Redis 布隆过滤器

• 可扩展性 Bloom 过滤器：一旦 Bloom 过滤器达到容量，就会在其上创建一个新的过滤器，不存在重启即失效或者定时任务维护的成本：基于 Google 实现的布隆过滤器需要启动之后初始化布隆过滤器
• 缺点：需要网络 IO，性能比 Google 布隆过滤器低

0x03：缓存击穿，热点 key 重建缓存问题

可能造成的原因

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

危害

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

解决方案

• 互斥锁

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

public String getKey(String key){
    String value = redis.get(key);
    if(value == null){
        // 设置互斥锁的key
        String mutexKey = "mutex:key:"+key;
        // 给这个key上一把锁，ex 表示只有一个线程能执行，过期时间为 180 秒
        if(redis.set(mutexKey,"1","ex 180","nx")){
          value = db.get(key);
          redis.set(key,value);
          redis.delete(mutexKety);
        }else{
          // 其他的线程休息100毫秒后重试
          Thread.sleep(100);
          getKey(key);
        }
   }
   return value;
}

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

0x04: 缓存雪崩，批量失效问题

可能造成的原因

缓存雪崩是指机器宕机或在我们设置缓存时采用了相同（近似）的过期时间，导致缓存在某一时刻大批量缓存数据同时（批量）失效

危害

请求全部转发到 DB，DB 瞬时压力过重，导致雪崩。

解决方案

• 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待
• 做二级缓存，A1 为原始缓存，A2 为拷贝缓存，A1 失效时，可以访问 A2，A1 缓存失效时间设置为短期，A2 设置为长期
• 不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀
• 如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中

source:https://www.yuque.com/nashihuakai/qlwgtg/bwcko4