Redis缓存击穿，缓存穿透，缓存雪崩

缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
举个简单的例子：我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

解决方案

• 在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。
• 从缓存取不到的数据，在数据库中也没有取到，这时也可以将对应Key的Value对写为null、位置错误、稍后重试这样的值具体取啥问产品，或者看具体的场景，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。

• 正常用户是不会在单秒内发起这么多次请求的，那网关层Nginx本渣我也记得有配置项，可以让运维大大对单个IP每秒访问次数超出阈值的IP都拉黑。

  Nginx配置限制同一个ip的访问频率

• 使用布隆过滤器

  布隆过滤器（BloomFilter）
  

缓存雪崩

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。

举个简单的例子：如果所有首页的Key失效时间都是12小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库，数据库必然扛不住，它会报一下警，真实情况可能DBA都没反应过来就直接挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。

解决方案

• 处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，我相信，Redis这点流量还是顶得住的。

• 设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

  缓存击穿

  缓存击穿是指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。
  缓存击穿，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。

  解决方案

• 设置热点数据永远不过期

• 加上互斥锁

  互斥锁代码示例

  @SneakyThrows
  public Object getData(String key) {
    // 从redis查询数据
    Object data = redisTemplate.opsForValue().get(key);
    // 如果不存在
    if (data == null) {
        // 获取锁
        if (lock.tryLock()) {
            try {
                // 去数据库查询
                data = getDataForDB(key);
                // 校验
                if (data != null) {
                    // 写入缓存
                    redisTemplate.opsForValue().set(key, data);
                }
            } catch (Exception e) {
                log.error("xxxxx");
            } finally {
                // 释放锁
                lock.unLock();
            }
        } else {
            // 睡一会儿再拿
            Thread.sleep(100);
            data = getData(key);
        }
    }
    return data;
  }

  总结

  一般避免以上情况发生我们从三个时间段去分析下：

• 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
  

• 事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免 MySQL 被打死。
• 事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。