缓存“三巨头”：穿透、击穿、雪崩全解析

欢迎大家来到IT世界,在知识的湖畔探索吧!

缓存穿透：查询无门的困扰

欢迎大家来到IT世界,在知识的湖畔探索吧!

缓存穿透的原理

在日常的数据查询过程中，缓存穿透是一个较为棘手的问题。它常常出现在我们查询一个在数据库中根本不存在的数据时，这时缓存就无法命中。按照正常的数据查询流程，缓存没找到数据，就会将请求转向数据库去查找。可如果大量这样不存在的数据请求涌来，每次请求都会直接打到数据库上，尤其是在高并发的情况下，数据库会承受极大的压力。

比如说，黑客可能会利用这一点，故意发送大量针对不存在数据的请求，以此来消耗系统资源，发动恶意攻击，就像发送大量查询错误 ID 或者不合法参数的请求，导致数据库不堪重负，甚至可能引发数据库崩溃，让整个系统陷入瘫痪状态。

缓存穿透的应对方法

面对缓存穿透，有几种常见且有效的应对办法：

缓存空数据：这种方法就是把空的数据也缓存起来，比如空字符串、空对象、空数组等等。当查询数据库返回为空结果时，将该请求对应的键存入缓存，并设置一个较短的过期时间。这样后续的相同请求就可以直接从缓存中获取空结果，而不用再去查询数据库了。它的优点是操作简单，容易实现；但缺点也比较明显，会消耗一定的内存，而且可能出现数据不一致的情况，例如缓存空对象的时候数据库原本没有对应数据，但之后数据库有了对应数据，这时缓存和数据库的数据就不一致了，只能等待过期时间到了再次查询才能保持一致。

使用布隆过滤器：布隆过滤器通过哈希算法来拦截一定不存在的数据。它本质上是由一个合适大小的位数组加上一系列的哈希函数组成。可以将所有可能存在的数据哈希到一个足够大的 bitmap 中，对于一个一定不存在的数据，会被这个 bitmap 拦截掉，从而避免了对底层数据库的查询压力。例如在实际应用中，先维护一个布隆过滤器，存储所有有效的 ID 或键，当接收到请求时，先查询布隆过滤器，如果返回不存在，那就直接返回空结果，不再去查询数据库了。它的优点是内存占用相对较少，并且没有多余的 key 产生；不过缺点是实现起来较为复杂，而且存在误判的可能，就是说存在的数据可能存在，不存在的数据一定不存在。

设置可访问名单（白名单）：提前设定好允许访问的数据范围，也就是白名单，只有在名单内的数据请求才能进一步去查询缓存和数据库，这样能从源头上减少非法或不存在数据的请求量。但它的局限性在于名单需要提前准确配置，如果业务数据变动频繁，维护成本会比较高。

进行实时监控：实时关注系统的请求情况和数据库的压力指标等，一旦发现有异常的大量针对不存在数据的请求，及时采取相应措施，比如临时限制请求频率或者报警通知相关人员来处理。不过这要求有完善的监控系统和配套的应急处理机制，对运维等方面的要求较高。

不同的方法适用于不同的场景，我们可以根据实际业务情况综合运用这些方法，尽可能地降低缓存穿透带来的风险，保障系统的稳定运行。

缓存击穿：单点失效的危机

缓存击穿的原理

在高并发的场景下，缓存击穿是一个不容忽视的问题。当某个热点数据对应的缓存过期了，而恰好在这个时间点，又有大量的并发请求同时来访问该数据，这时由于缓存中已经没有这份数据了，这些请求就会瞬间都打到后端数据库上。

比如说，在电商平台举办大型促销活动时，像一些热门商品的详情信息通常会被缓存起来以减轻数据库压力。假如某款爆款手机的商品详情缓存设置了一个过期时间，在促销活动的某个高峰时段，这个缓存刚好过期失效了，而此时大量用户同时点击查看这款手机的详情页，众多请求发现缓存里没数据了，就一股脑地全都涌向数据库去获取商品信息，如此巨大的并发量很可能一下子就压垮数据库，导致数据库响应变慢甚至出现服务不可用的情况。再比如一些热门的新闻资讯页面，在新闻刚发布的那段时间访问量极大，属于热点数据，如果缓存过期又逢大量用户访问，同样会出现缓存击穿的问题，让数据库承受极大压力。

缓存击穿的应对方法

面对缓存击穿，有以下几种有效的应对策略：

预先设置热门数据：在系统的高流量访问时段到来之前，比如电商大促活动前、热门节目直播前等，提前把那些预计会成为热点的数据存入到缓存里，像热门商品详情、热门直播频道信息等，并适当加大这些热门数据在缓存中 key 的时长，确保在高并发访问期间，这些数据能一直在缓存中，减少缓存失效带来的数据库访问压力。不过这种方法需要对业务有较好的预判能力，要能较为准确地提前确定哪些数据会成为热点，不然可能会造成缓存空间的浪费或者遗漏部分热点数据。

实时调整热门数据的缓存过期时长：通过现场监控，实时观察哪些数据正处于高访问热度状态，然后根据实际情况动态地调整这些热门数据的缓存过期时间。例如，发现某款商品在某个时间段内的访问量突然飙升，成为了热点商品，那就及时延长它的缓存过期时长，避免在高并发访问时缓存突然失效而引发击穿问题。但这要求有完善的监控系统以及高效的运维响应机制，能及时捕捉到数据热度的变化并做出调整。

使用锁机制（如 Redis 的 SETNX 操作）：当缓存失效的时候（也就是判断拿出来的值为空时），不是立即去访问数据库加载数据，而是先使用缓存工具带成功操作返回值的操作，比如 Redis 的 SETNX（SET if Not eXists，只有当指定的 key 不存在时才进行设置操作）去设置一个 mutex key。当这个操作返回成功时，意味着当前线程获取到了锁，然后该线程再去进行访问数据库并回设缓存的操作，操作完成后最后删除 mutex key；要是操作返回失败，那就证明有其他线程已经在访问数据库了，当前线程就睡眠一段时间后再重试整个获取缓存的流程。不过这种方式在高并发情况下可能会出现较多线程等待锁释放的情况，一定程度上会影响系统的响应速度，所以需要合理设置等待时间等参数，在保证避免缓存击穿的同时，尽量降低对系统性能的影响。

不同的应对方法适用于不同的业务场景以及高并发程度，在实际应用中，可以根据具体的系统特点、业务需求以及流量情况等综合选择和运用这些策略，最大程度地保障系统在面对缓存击穿问题时的稳定性和高效性。

缓存雪崩：集体失效的风暴

缓存雪崩的原理

在缓存系统的运用过程中，缓存雪崩是一个不容小觑的问题。它指的是大量缓存对象在同一时间失效或过期，进而导致大量请求直接打到后端存储系统上，使得后端系统的压力骤增，甚至有可能引起系统崩溃的情况。

通常来说，缓存雪崩容易在以下几种状况下发生：

• 大规模缓存失效：比如缓存服务出现故障、服务器重启等情况时，大量缓存对象会在同一时间失效，这时众多请求就只能直接去访问后端存储系统了。举个例子，若整个缓存服务器突然宕机重启，重启后缓存数据全部清空，相当于所有缓存同时失效，原本依靠缓存处理的大量请求就会一股脑地涌向数据库等后端存储。

• 同时过期：当多个缓存对象被设置了相同的过期时间，或者由于某些特殊原因导致它们同时过期时，也会造成大量请求直接去请求后端，这无疑加大了后端的负载。例如，在一个电商系统中，很多商品详情缓存都被统一设置为每天凌晨 2 点过期，那么到了这个时间点，大量商品的缓存失效，众多查看商品详情的请求就会全部打到数据库上。

• 单一资源热点：当某个热点资源对应的缓存失效时，大量请求同时来访问这个资源，可后端系统往往无法承受这么高的并发压力，进而可能引发雪崩效应。就像热门的演唱会门票开售时，相关票务信息是热点数据，缓存一旦失效，大量抢票的请求同时去访问数据库获取票务详情，很容易就把数据库压垮了。

缓存雪崩的应对方法

为了有效防止缓存雪崩，我们可以采取以下几种常用的方法：

• 设置随机的失效时间：可以给缓存对象设置一个稍微有差异的随机失效时间，以此避免大量缓存对象在同一时间失效。例如，使用编程语言中的随机函数，假设原本缓存过期时间统一设置为 60 分钟，现在通过代码让其在 50 分钟到 70 分钟这个区间内随机生成一个过期时间，像 Python 中可以利用 random 模块来实现类似功能，这样各个缓存的过期时间就分散开了，大大降低了集体失效的概率。

• 分布式锁机制：在缓存失效时，使用分布式锁机制，只允许一个请求去加载缓存并更新，其他请求则等待这个结果。比如基于 Redis 实现分布式锁，当缓存失效，多个请求同时到来时，只有一个请求能成功获取到锁，去数据库查询数据并更新缓存，其余请求等待该锁释放后再去获取最新缓存数据，这样就避免了大量请求同时直接访问后端存储系统，防止对后端造成过大压力。

• 异步加载缓存：可以在缓存失效前，提前异步加载缓存，使得缓存始终处于可用状态，从而避免雪崩效应。例如在系统低峰时段，通过后台任务或者定时任务去提前查询数据库，把即将过期的数据重新加载到缓存中，保证在高流量时段即使部分缓存正常过期了，新的数据也已经提前准备好在缓存里了，像一些资讯类平台，夜间可以异步更新白天热门文章的缓存数据。

• 多级缓存策略：采用多级缓存的策略，将缓存对象分散存储在不同级别的缓存中，以此降低单一缓存失效对整个系统的影响。常见的有本地缓存（如内存缓存）搭配远程缓存（如 Redis 缓存），先从本地缓存中查找数据，如果没有再去远程缓存查找，最后才去数据库获取。这样即使某一级缓存出现大规模失效的情况，其他级别的缓存还能继续分担一部分请求压力，保障系统的正常运行。

• 监控和预警机制：实时监控缓存系统的状态并设置预警机制，一旦发现异常，及时采取相应措施防止进一步的缓存雪崩。比如实时关注缓存的命中率、缓存对象的过期数量等指标，当缓存命中率突然大幅下降或者过期数量剧增等异常情况出现时，及时发出警报通知运维人员，运维人员可以采取临时增加缓存服务器、调整缓存策略等手段来避免雪崩情况恶化，保障系统稳定。

缓存问题的综合防范与总结

三种缓存问题的关联与差异

缓存穿透、缓存击穿和缓存雪崩这三种缓存问题，虽然表现形式有所不同，但它们之间存在着一定的关联，同时也有着明显的差异，了解这些对于我们准确把握和应对这些问题至关重要。

首先来说说它们的产生原因方面的相同点和不同点。相同点在于，这三种问题的出现都与缓存的失效或者无法有效命中相关，进而导致请求过多地打到数据库上，给数据库带来较大压力。不同点则较为显著，缓存穿透是由于大量查询根本不存在于缓存和数据库中的数据引发的，常见于恶意攻击或者不合理的参数校验场景，例如黑客故意发送大量针对不存在的用户 ID 等数据的请求；缓存击穿侧重于在高并发情况下，某个热点数据的缓存过期，使得大量并发请求瞬间直接访问数据库，像电商大促时热门商品详情缓存过期就容易出现这种情况；而缓存雪崩往往是因为大量缓存对象在同一时间失效或者缓存服务出现故障等原因，致使众多请求同时涌向数据库，比如缓存服务器重启后所有缓存数据清空，或者大量缓存被统一设置了相同的过期时间而同时过期。

在最终影响方面，它们的相同之处是都会使得数据库承受巨大的压力，严重情况下可能导致数据库响应变慢、服务不可用甚至崩溃，进而影响整个系统的正常运行。但从影响的范围和程度来看又有差异，缓存穿透更多是持续不断的不存在数据的请求对数据库造成消耗；缓存击穿通常是针对某一热点数据的高并发请求冲击数据库，影响相对集中在某个热点数据对应的数据库操作上；缓存雪崩则是大面积的缓存失效引发的大量请求冲击数据库，波及范围更广，往往对整个系统的稳定性影响更大。

应对侧重点上，缓存穿透主要侧重于防止那些不合理的、不存在数据的请求打到数据库，比如可以通过布隆过滤器提前拦截一定不存在的数据，或者缓存空数据避免重复查询等方式。缓存击穿重点在于解决热点数据缓存过期瞬间的高并发访问问题，像采用锁机制保证只有一个线程去访问数据库并更新缓存，或者提前设置好热门数据不过期等策略。缓存雪崩的应对更强调从整体上避免大量缓存同时失效，例如设置随机的缓存失效时间，或者采用分布式缓存等方式来提高缓存的可用性，同时还需要做好监控和预警，以便及时发现并处理异常情况。

通过对这三种缓存问题在产生原因、最终影响以及应对侧重点等方面的对比分析，我们能够更清晰地区分它们，从而在实际的系统开发和运维过程中，根据具体的业务场景，更精准地采取相应的措施来防范和解决这些问题，保障系统的稳定高效运行。

系统缓存策略的整体规划建议

在搭建和维护缓存系统时，为了有效防范缓存穿透、缓存击穿以及缓存雪崩这三种常见的缓存问题，我们需要从初始设计、参数配置到日常运维等多个环节进行综合考虑，制定全面且具备前瞻性的缓存策略，这对于系统的稳定运行有着举足轻重的作用。

在初始设计阶段，要充分考虑业务的特点和数据的访问模式。比如，对于电商类业务，热门商品的详情、销量排名靠前的商品信息等通常属于热点数据，在设计缓存时就需要对这类数据有特殊的缓存策略规划，像可以为其分配更大的缓存空间，或者设置单独的缓存区域进行管理，确保其能高效地被缓存和读取，减少缓存击穿的风险。同时，要根据业务可能出现的请求量级预估缓存服务器的承载能力，选择合适的缓存技术和架构，例如是采用单机缓存还是分布式缓存（如 Redis 集群等），分布式缓存能在一定程度上提高缓存的可用性，降低缓存雪崩带来的全盘崩溃风险。

参数配置环节至关重要，针对缓存穿透，可以合理设置布隆过滤器的相关参数，如哈希函数的个数、位数组的大小等，在保证拦截不存在数据效果的同时，尽量降低误判率。对于缓存的过期时间设置，要避免大量缓存设置相同的过期时间，尽可能地让其分散开来，防止缓存雪崩的发生。例如在设置商品详情缓存过期时间时，可以利用随机函数生成一个合理的时间区间内的过期时间，像在 30 分钟到 60 分钟之间随机取值。而对于热点数据的缓存过期时长，要根据业务热度变化情况进行动态调整，避免出现缓存击穿，比如在电商大促期间延长热门商品的缓存时长，大促结束后再恢复常规时长。

日常运维方面，要建立完善的监控体系，实时关注缓存的命中率、缓存对象的过期数量、数据库的负载压力等关键指标。一旦发现缓存命中率突然大幅下降，可能预示着有缓存穿透或者雪崩的迹象；若发现某个热点数据对应的缓存频繁过期且数据库压力增大，那就可能是缓存击穿问题。当出现异常情况时，要有配套的应急处理机制，比如及时限制异常请求的频率、调整缓存策略（如临时延长部分缓存的过期时间）、增加缓存服务器资源等。同时，定期对缓存系统进行性能评估和优化，根据业务的发展和变化，及时调整缓存的相关配置和策略，例如随着业务数据量的增加，适时扩大缓存空间或者增加缓存服务器节点数量等。

总之，只有从系统缓存策略的各个环节全面规划，提前考虑到可能出现的缓存问题，并做好相应的防范和应对措施，才能确保缓存系统在面对高并发等复杂业务场景时稳定可靠地运行，充分发挥其减轻数据库压力、提升系统整体性能