背景
在现代软件架构中，缓存的应用已经非常普及。缓存的使用在面试和实践中都是避不开的硬技能、硬知识，如果你说还不太熟悉缓存的使用，可能都不好意思说自己是程序员。
在上篇文章《如果不知道这4种缓存模式，敢说懂缓存吗？》中，我们介绍了缓存使用的四种策略，如果能够结合不同的场景进行灵活运用，你已经超过了大多数人。毕竟，那四种策略，很多开发多年的人可能都没听说过。
这篇文章，带大家进一步学习在缓存使用中不得不考虑三个特殊场景：缓存穿透、缓存雪崩、缓存击穿。
为什么说不得不考虑？因为如果不考虑这些特殊的场景，在高并发的情况可能直接导致系统崩溃。下面以常见的Redis缓存组件为例来讲解这三种场景及解决方案。
大前提
当我们使用缓存时，目标通常有两个：第一，提升响应效率和并发量；第二，减轻数据库的压力。
而本文中所提到的这三种场景：缓存穿透、缓存雪崩和缓存击穿的发生，都是因为在某些特殊情况下，缓存失去了预期的功能所致。
当缓存失效或没有抵挡住流量，流量直接涌入到数据库，在高并发的情况下，可能直接击垮数据库，导致整个系统崩溃。
这就是我们需要知道的大前提，而缓存穿透、缓存雪崩和缓存击穿，只不过是在这个大前提下的不同场景的细分场景而已。
缓存穿透
大多数情况，缓存可以减少数据库的查询，提升系统性能。
通常流程是：一个请求过来，先查询是否在缓存当中，如果缓存中存在，则直接返回。如果缓存中不存在对应的数据，则检索数据库，如果数据库中存在对应的数据，则更新缓存并返回结果。如果数据库中也不存在对应的数据，则返回空或错误。
缓存穿透（cache penetration）是用户访问的数据既不在缓存当中，也不在数据库中。出于容错的考虑，如果从底层数据库查询不到数据，则不写入缓存。这就导致每次请求都会到底层数据库进行查询，缓存也失去了意义。当高并发或有人利用不存在的Key频繁攻击时，数据库的压力骤增，甚至崩溃，这就是缓存穿透问题。
缓存穿透发生的场景一般有两类：
- 原来数据是存在的，但由于某些原因（误删除、主动清理等）在缓存和数据库层面被删除了，但前端或前置的应用程序依旧保有这些数据；
- 恶意攻击行为，利用不存在的Key或者恶意尝试导致产生大量不存在的业务数据请求。