概述
Redis 的缓存异常问题，除了数据不一致问题外，还会面临其他三个问题，分别是缓存雪崩、缓存击穿、缓存穿透。这三个问题，一旦发生，会导致大量的请求积压到数据库。若并发量很大，就会导致数据库宕机或故障，这是很严重的生产事故。
1.缓存雪崩
缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理，应用将大量的请求发送到数据库层，导致数据库层压力激增。
造成缓存雪崩的原因一般有两个，应对的方案也不同。
1.1第一个原因是：缓存中有大量的数据同时过期，导致大量请求无法得到处理
具体来说，当数据保存在缓存中，并且设置了过期时间时，如果在某一时刻，大量数据同时过期，此时应该在访问这些数据就发生缺失。紧接着，应用就会把请求发送给数据库，从数据库中读取数据。如果应用的并发请求量很大，那么数据库的压力也就很大，这会加剧影响到数据库的其他正常业务请求处理。
针对大量数据同时失效带来的缓存雪崩，有两种解决方案。
A.可以避免给大量的数据设置相同的过期时间
如果业务层的确要求有些数据同时过期，你可以在用 EXPIRE 命令给每个数据过期时，给过期时间增加一个较小的随机数（例如，随机增加1~3分钟），这样一来，不同数据的过期时间有所差别，但差别有不会太大，既避免了大量数据同时过期，又保证了这些数据基本在相近的时间失效，仍能满足业务需求。
B.还可以通`服务降级来应对雪崩。
所谓服务降级，是指发送缓存雪崩时，针对不同的数据采取不同的处理方式。
当业务访问的是非核心数据（如电商商品属性）时，暂时停止从缓存中查询这些数据，而是直接返回预定义信息、空值或错误信息。
当业务应用访问的是核心数据（例如商品库存）时，仍然运行查询缓存，如果缓存缺失，也可以继续通过数据库读取。
这样一来，只有部分过期数据的请求会发送到数据库，数据库的压力也就没有那么大了。
1.2 第二个原因是 Redis 实例发送故障宕机了，无法处理请求，这会导致大量请求一下子积压到数据库层，从而发生雪崩
一般来说，一个 Redis 实例可以支持万级别的请求处理吞吐量，而单个数据库可能只支持数钱级别的吞吐量。由于缓存雪崩，Redis 缓存失效，所以数据库可能因压力过大而崩溃。
有两个建议可以应对 Redis 宕机而引发的缓存雪崩。
第一个建议，是在业务系统中实现服务熔断或请求限流机制
服务熔断，是指在发送缓存雪崩时，为了防止引发连锁的数据库雪崩，甚至是整个系统的崩溃，我们暂停业务应用对缓存系统的接口访问。即业务应用调用缓存接口时，客户端并不把请求发给 Redis 实例，而是直接返回等到 Redis 实例重新恢复后，再允许应用请求发送到缓存系统。这样就避免了大量请求应缓存缺失，而积压到数据库。
在业务系统运行时，我们可以监测 Redis 缓存所在机器和数据库所在机器的负载指标，如每秒请求书、CPU 利用率等。如果发现 Redis 缓存确实宕机了，而数据库所在机器的负载压力突然增加（例如，每秒请求数激增），此时就发生缓存雪崩了。我们可以启动熔断机制，暂停业务应用对缓存服务的访问，从而降低数据库的访问压力。
熔断服务虽然可以保证数据库的正常运行，但是暂停了整个缓存系统的访问，对业务应用的影响范围大。为了尽可能减少这种影响，我们也可以进行请求限流。
请求限流是指，我们在业务系统发请求入口前端控制每秒进入系统的请求数，避免过多的请求被发送到数据库。
假设业务系统正常运行是，请求入口允许每秒进入系统的请求是 1 万个，其中，9000 个请求都能在缓存中处理，只有 1000 个请求会被应用发送到数据库。
一旦发生了缓存雪崩，数据库每秒的请求突然增加到 1 万个，此时，就可以启动请求限流机制，在请求入口前端只允许每秒进入 1000 个请求，再多的请求就会在入口前端直接拒绝服务。所以，使用了请求限流，就可以避免大量并发请求压力传递到数据库层。
使用熔断或是请求限流，来应对 Redis 实例宕机导致的缓存雪崩问题，属于“事后诸葛亮”。
第二个建议是事前预防
通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis 缓存的主节点故障宕机了，从节点还可以切换成主节点，继续提供缓存服务，避免了由于缓存实例宕机而导致的缓存雪崩问题。
2.缓存击穿
缓存击穿是指，某个访问非常频繁的热点数据的请求，无法在缓存中进行处理，紧接着，该访问该数据集的大量请求，一下子都发送到了后端数据库，导致了数据库压力激增，会影响数据库处理其他请求。缓存击穿的情况，经常发送在热点数据过期失效时，如下所示：
为避免缓存击穿给数据库带来的激增压力，解决办法是：对于访问特别频繁的热点数据，我们就不设置过期时间了。这样一样，对热点数据的服务请求，都可以在缓存中进行处理。
3.缓存穿透
缓存穿透是指要访问的数据既不在 Redis 缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库，但是发现数据库中也没有要访问的数据。此时，应用也无法从数据库中读取数据再写入缓存，这样一来缓存就成了"摆设"。如果应用持续有大量请求访问数据库，就会同时给缓存和数据库带来巨大压力：
缓存穿透一般在什么时候发生？
- 业务层误操作：缓存中和数据库中的数据被误删了，所以缓存中和数据库中都没有数据。
- 恶意攻击：专门访问数据库中没有的数据。
一共有三种方案来应对缓存穿透的问题
3.1 第一种方案是缓存空值或缺省值
一旦发生缓存穿透，我们就可以针对查询的数据，在 Redis 中缓存一个空值或是业务层商定的缺省值。紧接着，应用发送后的请求在进行查询时，就可以直接从 Redis 中读取空值或缺省值返回给业务应用了，避免了把大量请求发送给数据库。
3.2 第二种方案是，使用布隆过滤器快速判断数据是否存在，避免从数据库中查询数据是否存在，减去数据库压力
先看下布隆过滤器是如何工作的。布隆过滤器由一个 初值都为 0 的 bit 数组 和 N 个哈希函数 组成，它可以用来快速判断某个数据是否存在。当我们想标记某个数据存在时（例如，数据已被写入数据库），布隆过滤器会通过三个操作完成标记：
- 首先，使用 N 个哈希函数，分别计算这个数据的哈希值，得到 N 个哈希值。
- 然后，把这个 N 个哈希值对 bit 数组的长度取模，得到每个哈希值在数组中的位置。
- 最后，我们把对应的 bit 位设置为 1，这就完成了在布隆过滤器中标记数据的操作。
如果数据不存在（例如，在数据库中没有写入数据），我们也就没有用布隆过滤器标记过数据，那么， bit 数组对应的 bit 位的值仍为 0。
当需要查询某个数据时，我们就执行刚刚的计算过程，先得到这个数据在 bit 数组中对应的 N 个位置。紧接着，查看 bit 数组中这个 N 个位置上的 bit 值。只要这 N 个 bit 值有一个不为 1，这就表明布隆过滤器没有对该数据做过标记，所以，查询的数据一定没有在数据库中保存。
- 图中布隆过滤器是一个包含 10 个 bit 位的数组，使用 3 个哈希函数。
- 当在布隆过滤器中标记 X 时，X 会被计算 3 次哈希值，并对 10 取模，取模的结果分别是 1、3、7。
- 所以，bit 数组的第 1、3、7 位被设置为 1。
- 当应用要查询 X 时，只有查看数组的第 1、3、7 位是否为 1。只要有一个为 0，那么 X 就肯定不在数据库中。
正式基于布隆过滤器的快速检测特性，我们可以在把数据写入数据库时，使用布隆过滤器做个标记。当缓存缺失后，应用查询数据库时，可以通过查询布隆过滤器快速判断数据是否存在。如果不存在，就不用再去数据库中查询了。这样一来，及时发送了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会积压请求到数据库。布隆过滤器可以使用 Redis 实现，本身就能承受较大的并发压力。
3.3 最后一种方案是在请求入口的前端进行检测
缓存穿透的一个原因是有大量的恶意请求访问不存在的数据，所以，一个有效的应对方案是在请求入口前端，对业务系统接收到的请求进行合法性检测，把恶意请求（例如请求参数不合发、请求字段不存在）直接过滤掉，不让他们访问后端缓存和数据库。这样一来，也就不会出现缓存穿透问题了。
4.小结
我把三大问题的原因和应对方案总结到一张表格上。
| 问题 | 原因 | 应对方案 |
|---|---|---|
| 缓存雪崩 | 大量数据同时过期 缓存实例宕机 | 给缓存数据的过期时间加上小的随机数，避免同时过期 服务降级 服务熔断 请求限流 Redis主从集群 |
| 缓存击穿 | 访问非常频繁的热点数据过期 | 不给热点数据设置过期时间 |
| 缓存穿透 | 缓存和数据库中都没有要访问的数据 | 缓存空值或缺省值 请求使用布隆过滤器快速判断 请求入口前端对请求合法性进行检查 |
最后，要强调以下，服务熔断、服务降级、请求限流这些方法都属于“有损”方案，在保证数据库和整体系统稳定的同事，会对业务应用带来负面影响。
所以，建议尽量使用预防方案：
- 针对缓存雪崩，合理的设置数据过期时间，以及搭建高可靠缓存集群。
- 针对缓存击穿，在缓存访问非常频繁的热点数据时，不要设置过期时间。
- 针对缓存穿透，提前在入口前端实现恶意请求检测、使用不容过滤器快速判断，或者规范数据库的数据删除操作，避免误删。
