如何理解Redis缓存穿透？

描述

当访问一个缓存和数据库都不存在的key时，请求会直接打到数据库上，并且查不到数据，没有办法写缓存，所以下一次同样会打到数据库上。这时缓存就好像被“穿透”了一样，没有起到任何作用。如果有恶意的请求，故意去查询不存在的key，请求量就很大，会对后端系统造成很大的压力，甚至数据库挂掉，这就叫做缓存穿透。

如何避免？

方案1：接口校验。在正常业务流程中，可能还会存在少量访问不存在key的情况，但是一般不会出现大量的情况，所以这种场景很大可能性时遭到非法攻击。可以在最外层先做一层校验，用户鉴权，数据合法性校验等，例如商品查询中，商品的ID是正整数，则可以直接对非正整数直接过滤等。

方案2：缓存空值。当访问缓存和DB都没有查询到值时，可以将空值写进缓存，但是要设置较短的过期时间，改时间需要根据产品业务特性来设置。

方案3：布隆过滤器。使用布隆过滤器存储所有可能访问的key，不存在的key直接被过滤，存在的key则在进一步查询和数据库。可把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。

如何理解Redis缓存击穿？

描述

某一个热点key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大，压力骤增，甚至可能打垮数据库。

如何避免

方案1：热点数据不设置过期时间，后由定时任务去异步加载数据，更新缓存。这种方式适用于比较极端 的场景，例如流量特别大的场景，使用时需要考虑业务能接受数据不一致的时间，还有就是异常情况的处理，不要到时候缓存刷新不上，一直时脏数据就完了。

方案2：应用互斥锁。在并发的多个请求中，保证只有一个请求线程能拿到锁，并执行数据库查询操作，其他线程拿不到锁就阻塞等待，等到第一个线程将数据写入缓存后直接去走缓存。

关于互斥锁的选择，网上看到的大部分文章都是选择 Redis 分布式锁，因为这个可以保证只有一个请求会走到数据库，这是一种思路。但是其实仔细想想的话，这边其实没有必要保证只有一个请求走到数据库，只要保证走到数据库的请求能大大降低即可，所以还有另一个思路是 JVM 锁。JVM 锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。需要注意的是，无论是使用“分布式锁”，还是“JVM 锁”，加锁时要按 key 维度去加锁。我看网上很多文章都是使用一个“固定的 key”加锁，这样会导致不同的 key 之间也会互相阻塞，造成性能严重损耗。

使用 redis 分布式锁的伪代码，仅供参考：

  2. public Object loadData(String key) throws InterruptedException {
  3.     Object value = redis.get(key);
  4.     // 缓存值过期
  5.     if (value == null) {
  6.         // lockRedis：专门用于加锁的redis；
  7.         // "empty"：加锁的值随便设置都可以
  8.         if (lockRedis.set(key, "empty", "PX", lockExpire, "NX")) {
  9.             try {
  10.                 // 查询数据库，并写到缓存，让其他线程可以直接走缓存
  11.                 value = loadDataFromDb(key);
  12.                 redis.set(key, value, "PX", expire);
  13.             } catch (Exception e) {
  14.                 // 异常处理
  15.             } finally {
  16.                 // 释放锁
  17.                 lockRedis.delete(key);
  18.             }
  19.         } else {
  20.             // sleep30ms后，进行重试
  21.             Thread.sleep(30);
  22.             return getData(key);
  23.         }
  24.     }
  25.     return value;
  26. }

如何理解Redis缓存雪崩？

描述
缓存雪崩是当缓存服务器重启或者大量缓存集中在某一个时刻失效，造成瞬时数据库请求量大，压力骤增，导致数据库崩溃。缓存雪崩有点像“升级版的缓存击穿”，缓存击穿是一个热点key，而缓存雪崩是一组热点key。

如何避免

方案1：打散过期时间。不同的key，是指不同的过期时间，（例如使用一个随机值），让缓存失效的时间点尽量均匀。

方案2：做二级缓存。A1为原始缓存，A2为拷贝缓存，A2失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

方案3：加互斥锁。缓存失效后，通过加锁或者队列来控制写缓存的线程数量。比如对某个key只允许一个线程操作缓存，其他线程等待。

方案4：热点数据不设置过期时间。该方式和缓存击穿一样，要着重考虑刷新的时间间隔和数据异常如何处理的情况。