说明
缓存穿透、缓存击穿和缓存雪崩是Redis面试当中和实际开发中，经常需要考虑的一个问题。很多人对该问题的产生、原因和解决方案还是不够清晰。其实大家针对该三种情况，去仔细分析一个产生的原理就能很好的找到一个好的解决方案。 本文通过定义、案例、危害和解决方案的几个角度，来帮助你快速了解该三个问题。
三者比较
- 缓存穿透、缓存击穿和缓存雪崩都是因为缓存中数据不存在，导致走数据库去查询数据。
- 由于缓存数据不存在，所有的请求都会走到数据库，因此会导致数据库的压力过大甚至出现服务崩溃，导致整个系统无法使用。
缓存穿透
定义：缓存穿透是由于客户端求的数据在缓存中不存在，然后去查询数据库，然而数据库没有客户端要查询的数据，导致每一次请求都会走数据库查询操作。 举例：客户端请求商品详情信息时，携带一个商品ID，此时该商品ID是不存在的(不管是缓存中还是数据库中)。导致每一次请求该ID商品的数据信息都会走数据库。 危害：由于请求的参数对应的数据根本不存在，会导致每一次都会请求数据库，增加数据库的压力或者服务崩溃，更有甚至影响到其他的业务模块。经常发生在用户恶意请求的情况下会发生。 解决方案：
- 根据请求的参数缓存一个null值。并且为该值设置一个过期时间，可以将时间设置短暂一点。
- 使用布隆过滤器，首先通过布隆过滤器进行筛选，如果在过滤器中存在则去查询数据库，然后添加到缓存中。如果不存在则直接返回客户端数据不存在。
- 由于缓存穿透可能是用户发起恶意请求，可以将用户ip给记录下来，针对恶意的ip请求进行封禁。
缓存击穿
定义：缓存击穿是因为部分热点key不存在，导致走数据库查询。增加了数据库的压力。这种压力可能是瞬间的，也可能是比较持久的。 举例：有一个或者多个热门的商品，用户查看商品详情时携带商品的ID以获取到商品的详情信息。此时恰好缓存中的数据过期了，因此来的所有请求都要走数据库去查询。 危害：相对缓存穿透而言，该数据在数据库中是存在的，只是因为缓存过期了，导致要走一次数据库，然后在添加到缓存中，下次请求就能正常走缓存。所谓的危害同样的还是针对数据库层面的危害。 解决方案：
- 加互斥锁。针对第一个请求，发现缓存中没有数据，此时查询数据库添加到缓存里面。这样后面的请求就不需要走数据库查询。
- 增加业务逻辑过期时间。在设置缓存时，我们可以添加一个缓存过期时间。每次去读取的时候，做一个判断，如果这个过期时间与当前时间小于一个范围，触发一个后台线程，去数据库拉取一下数据，接着更新一下缓存数据和缓存的过期时间。其实原理就是代码层面给缓存延长缓存时长。
- 数据预热。实现通过后台把数据添加到缓存里面。例如秒杀场景开始前，就把商品的库存添加到缓存里面，这样用户请求来了之后，就直接走缓存。
- 永久不过期。在给缓存设置过期时间时，让它永久不过期。后台单独开启一个线程，来维护这些缓存的过期时间和数据更新。
缓存雪崩
定义：前面在说到缓存击穿，是因为缓存中的部分热点key失效，导致大量请求走数据库。然而缓存雪崩其实也是同样的道理，只不过这个更严重而已，是大部分缓存的key失效，而不是一个或者两个key失效。 举例：在一个电商系统中，某一个分类下的商品数据在缓存中都失效了。然而当前系统的很多请求都是该分类下面的商品数据。这样就导致所有的请求都走数据库查询。 危害：由于一瞬间大量的请求涌入，每一个请求都要走数据库进行查询。数据库瞬间流量涌入，严重增加数据库负担，很容易导致数据库直接瘫痪。 解决方案：
- 缓存时间随机。因为某一时间，大量的缓存失效，说明缓存的过期时间比较集中。我们直接将过期的时间设置为不集中，随机打乱。这样缓存过期时间相对不会很集中，就不会出现同一时刻大量请求走数据库进行查询操作。
- 多级缓存。不单纯的靠Redis来做缓存，我们也可以使用memcached来做缓存(这里只是举一个例子，其他的缓存服务也可以)。缓存数据时，对Redis做一个缓存，对memcached做一个缓存。如果Redis失效了，我们可以走memcached。但这样增加了系统的架构难度，以及其他的各种问题，例如缓存多级更新。
- 互斥锁。缓存击穿中我们提到了使用互斥锁来实现，同样我们也可以用在雪崩的情况下。
- 设置过期标志。其实也可以用到缓存击穿中讲到的永久不过期。当请求时，判断过期时间，如果临近过期时间则设置一个过期标志，触发一个独立的线程去对这个缓存进行更新。
总结
- 缓存穿透是因为数据库本身没有该数据。
- 缓存击穿和缓存雪崩是数据库中存在该数据，只是缓存中的数据失效了，导致重新要查询一次数据库再添加到缓存中去。
- 缓存击穿是针对部分热点key，而缓存雪崩是大面积缓存失效。两则原理上其实是一样的，无非就是针对缓存的key的划分不同而已。
