缓存穿透、击穿和雪崩

一、缓存穿透：（即：缓存无数据，数据库也无数据）

• 造成原因：
  1、自身业务代码或者数据出现问题。
  2、如黑客恶意攻击、爬虫等，使用缓存和数据库均没有的key进行不断请求，导致数据库压力过大。

• 解决方案：
  1、对用户进行鉴权、对请求参数进行校验，不合理直接过滤。
  2、对查询不到的数据也放到缓存，value为空，设置一定的过期时间。（不太常用，因为如果是随机key就不起作用，且占缓存）
  3、使用布隆过滤器，快速判断key是否在数据库中存在，不存在直接返回。（最有效）

• 总结：第1种是最常用的策略，第2种不太常用，因为如果是随机key就不起作用，且占缓存，第三种最简单有效。实际使用中，可以1、3相结合。
  布隆过滤器:
  对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。
  
  布隆过滤器就是**一个大型的位数组和几个不一样的无偏 hash 函数。**所谓无偏就是能够把元素的 hash 值算得比较均匀。
  向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。
  向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。
  这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。
  可以用guvua包自带的布隆过滤器，引入依赖：

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>22.0</version>
</dependency>

二、缓存击穿：（即：缓存无数据，数据库有数据，key比较集中）

• 造成原因：如高并发的情况下，热点数据缓存过期，这时候会导致大量请求读不到缓存直达数据库，导致数据库瞬时压力过大。

• 解决方案：
  1、设置热点数据缓存永不过期。
  2、热点数据快过期时，通过另一个异步线程重新续命。
  3、当热点数据过期，重新从数据库加载数据到缓存时加上互斥锁并将缓存过期时间设置为一个时间段内的不同时间。

• 总结：第1种，数据量大时，缓存量会比较大，第2种，很好理解，但是需要另外的逻辑去维护，会增加系统的复杂度。实际使用中，可以1、3相结合。
  加载缓存时上互斥锁：

   /**
     * 此方法只允许一个线程重建缓存,其他线程等待重建缓存的线程执行完,重新从缓存获取数据即可
     * @param key
     * @return
 	 */
   public Product queryProductByCache(String key) {
    // 从缓存中获取数据
    Product product = redisCluster.get(key);
    // 缓存数据为空
    if (product == null) {
        //加锁
        if (redisCluster.setnx(lock_key, 1, 60) > 0) {
            try {
                // 从数据库中获取
                product = productMapper.query(key);
                //设置一个随机过期时间(60000到120000之间的一个随机数)
                int expireTime = new Random().nextInt(60000) + 120000;
                redisCluster.set(key, product, expireTime);
            } finally {
                redisCluster.del(lock_key);
            }

        } else {
            //double check
            if (redisCluster.get(key) == null) {
                //当前线程阻塞一小段时间，重新获取。
                Thread.sleep(100);
                queryProductByCache(key);
            }
        }
    }
    // 非空直接返回
    return product;
}

三、缓存雪崩：（即：缓存无数据，数据库有数据，key比较分散）

• 造成原因：如在高并发的情况下，缓存在极短时间内大量失效（如缓存挂了，或者设置了相同过期时间），所有请求会读数据库，容易导致数据库负载瞬间上升，乃至崩掉。如果重启数据库，立马又会被新的请求压崩。
  与缓存击穿的区别：它是大量缓存key的过期；而缓存击穿是热点数据缓存key过期后访问量瞬时增大。

• 解决方案：
  1、缓存的失效时间设置为随机值，避免同时失效。
  2、redis搭建高可用，主从+哨兵，redis cluster。
  3、服务限流、降级，避免数据库被瞬间压崩（如使用Hystrix组件）。

• 总结：第1种只能防止因缓存同时过期导致的缓存失效，第2种可以有效避免单台缓存挂掉的情况。第3种是使用一些策略提高服务的高可用，来避免缓存失效带来的影响，是辅助措施。 实际应用中最好可以1、2、3搭配。