从第一个缓存框架 Memcached 诞生以来，缓存就广泛地存在于互联网应用中。如果你的应用流量很小，那么使用缓存可能并不需要做多余的考虑。但如果你的应用流量达到了成百上千万，那么你就不得不考虑深层次的缓存问题：缓存穿透、缓存雪崩与缓存击穿。
1. 缓存穿透
缓存穿透是指查询一个一定不存在的数据，因为这个数据不存在，所以永远不会被缓存，所以每次请求都会去请求数据库。如果某些心怀不轨的人利用这个存在的漏洞去伪造大量的请求，那么很可能导致DB承受不了那么大的流量就挂掉了。
对于缓存穿透，有几种解决方案，一种是事前预防，一种是事后预防。
事前预防： 其实就是对所有请求都进行参数校验，把绝大多数非法的请求抵挡在最外层。例如对于获取用户信息的接口，我们可以对用户ID进行参数校验，对于用户ID未负数的请求直接拦截。但即使我们做了全面的参数校验，还是可能存在漏网之鱼，这时候就需要进行事后预防。
事后预防：指的是对于查询结果为空的请求，我们仍然将这个空的结果进行缓存，但是设置一个很短的过期时间（例如一分钟）。在这里我们可以看到，其实我们并没有完全预防非法请求，只不过是将非法请求的风险让承受能力更强的redis去承担，让承受能力稍弱的数据库更安全。
通过上面这两种处理方式，我们基本可以解决缓存穿透的问题。
事前预防解决80%的非法请求，剩下的20%非法请求则使用Redis转移风险。
2. 缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。
缓存雪崩导致的问题一般很难排查，如果没有事先预防，很可能要花很大力气才能找得到原因。对于缓存雪崩的情况，最简单的方案就是在原有失效时间的基础上增加一个随机时间（例如1-5分钟），这样每个缓存过期时间的重复率就会降低，从而减少缓存雪崩的发生。
3. 缓存击穿
如果你的应用中有一些访问量很高的热点数据，我们一般会将其放在缓存中以提高访问速度。另外，为了保持时效性，我们通常还会设置一个过期时间。
但是对于这些访问量很高的KEY，我们需要考虑一个问题：当热点KEY在失效的瞬间，海量的请求会不会产生大量的数据库请求，从而导致数据库崩溃？
其实上面这个问题就是缓存击穿的问题，它发生在缓存KEY的过期瞬间。对于这种情况，现在常用的解决方式有这么两种：互斥锁、永远不过期。
3.1互斥锁
互斥锁指的是在缓存KEY过期去更新的时候，先让程序去获取锁，只有获取到锁的线程才有资格去更新缓存KEY。其他没有获取到锁的线程则休眠片刻之后再次去获取最新的缓存数据。
通过这种方式，同一时刻永远只有一个线程会去读取数据库，这样也就避免了海量数据库请求对于数据库的冲击。
而对于上面说到的锁，我们可以使用缓存提供的一些原则操作来完成。例如对于 redis 缓存来说，我们可以使用其 SETNX 命令来完成。
public String get(key) {
String value = redis.get(key);
if (value == null) { //缓存过期
if (redis.setnx(key_mutex, 1, 1 ** 60) == 1) {
value = db.get(key);
redis.set(key, value, expireTime);
redis.del(key_mutex);
} else {
//休眠片刻后重试
sleep(50);
get(key);
}
} else {
return value;
}
}
上面的 key_mutex 其实就是一个普通的 KEY-VALUE 值，我们使用 setnx 命令去设置其值为 1。如果这时候已经有人在更新缓存KEY了，那么 setnx 命令会返回 0，表示设置失败。
3.2 永不过期
从缓存的角度来看，如果你设置了永远不过期，那么就不会有海量请求数据库的情形出现。此时我们一般通过新起一个线程的方式去定时将数据库中的数据更新到缓存中，更加成熟的方式是通过定时任务去同步缓存和数据库的数据。
但这种方案会出现数据的延迟问题，也就是线程读取到的数据并不是最新的数据。但对于一般的互联网功能来说，些许的延迟还是能接受的。
4. 总结
缓存穿透：指的是请求不存在的数据，从而使得缓存形同虚设，缓存层被穿透了。
缓存雪崩：则是指缓存在同一时间同时过期，就像所有雪块同一时刻掉下来，像雪崩一样。
缓存击穿：则是在某些热点缓存数据过期瞬间发生的。
缓存雪崩其实比较好理解，其解决方案也很简单，就是让过期时间变得更加均匀，自然就可以避免这种异常情况的发生。
而缓存穿透和缓存击穿则非常相似，但它们还是略有不同。
缓存穿透发生的前提是业务上的漏洞，导致出现了非法请求。
而缓存击穿只会发生于访问量很大的热点数据，并且是发生在其过期进行更新数据的瞬间。
