Redis穿透解决方案与预防措施，如何应对缓存穿透问题

为了解决Redis缓存穿透问题，最直接有效的办法是对于查询不到的数据也进行缓存，并设置一个较短的过期时间，同时配合布隆过滤器来预先过滤掉肯定不存在的数据请求。

什么是缓存穿透

缓存穿透指的是，用户请求的数据在数据库里根本不存在，因此这个请求每次都会绕过缓存直接去查询数据库。想象一下，如果有人恶意用一个不存在的用户ID反复查询，那么每次请求都会打到数据库上，这就像一根针直接穿透了缓存这层保护，给数据库带来巨大压力，甚至可能让它崩溃。

核心解决方案：缓存空对象

这是最简单直接的一招。当你发现某个查询在数据库里找不到结果时，不要什么都不做。你应该在Redis里把这个查询的Key也存下来，对应的值可以是一个特殊的标记，比如“NULL”或者一个空JSON对象，并给它设置一个比较短的过期时间，比如30秒到5分钟。这样，在短时间内，同样的恶意请求再来时，就会从Redis里拿到这个空值，不会再攻击数据库了。这个方法的好处是容易实现，但缺点是会浪费一点缓存空间来存放这些无效的Key。

预防性方案：使用布隆过滤器

布隆过滤器是一个很巧妙的数据结构，它能非常高效地判断一个元素“一定不存在”或者“可能存在”于一个集合里。我们可以在系统启动时，把数据库里所有可能存在的数据的ID（比如所有有效的用户ID）都加载到布隆过滤器里。当有查询请求过来时，先让这个请求经过布隆过滤器检查。如果过滤器说“这个ID肯定不存在”，那就直接返回空结果，根本不用去查缓存和数据库。只有过滤器说“可能存在”，才允许去查缓存或数据库。这相当于在缓存前面又加了一道高效的安检门，把大部分无效请求提前拦了下来。不过，布隆过滤器需要额外的维护，并且有极小的误判率（把存在的判为不存在，这种情况需要避免）。

结合使用与操作步骤

在实际应用中，我们通常会把上面两种方法结合起来用，效果更好。一个推荐的操作流程是这样的：
1. 请求到来，先检查布隆过滤器。如果数据肯定不存在，直接返回空。
2. 如果布隆过滤器允许通过，则查询Redis缓存。
3. 如果缓存命中，直接返回数据。
4. 如果缓存未命中，则查询数据库。
5. 如果数据库里有数据，将其写入Redis缓存，并返回数据。
6. 如果数据库里也没有数据，则在Redis中缓存一个空值（设置短过期时间），并返回空。同时，根据业务情况，可以考虑将这个不存在的Key也同步到布隆过滤器中，以强化后续的过滤效果。

其他辅助措施

除了上述方法，还有一些辅助手段可以帮助缓解问题。比如，对请求参数做严格的合法性校验，像ID必须是正数、符合一定格式等，把一些明显非法的请求在最外层就拒绝掉。也可以对接口进行限流，当某个IP或用户短时间内请求次数异常高时，对其进行限制或暂时封禁，防止恶意攻击。

FAQ

问：缓存空对象时，过期时间设置多长比较合适？
答：没有固定标准，需要根据业务来定。如果是不常变化的静态数据列表，可以设长一些，比如5-10分钟。如果是动态性很强的数据，可以设短一些，比如30-60秒。目的是在保护数据库和避免缓存过多垃圾数据之间取得平衡。

问：布隆过滤器需要把所有数据都存进去吗？会不会很大？
答：是的，通常需要初始化所有可能存在数据的键。它的空间占用相对于存储完整数据来说是非常小的，因为它只使用一个位数组和多个哈希函数来存储信息。对于亿级数据量，一个布隆过滤器可能只需要几百MB内存，在现代服务器上是可以接受的。也可以考虑使用可扩展的布隆过滤器。

问：除了Redis，其他缓存有类似问题吗？
答：是的，缓存穿透是缓存系统中的一个通用性问题，不仅仅发生在Redis上。只要使用了缓存层（如Memcached、本地缓存等）来加速数据库查询，都可能面临同样的问题。其核心解决方案（缓存空值、使用过滤器）的思想是相通的。

引用来源：本文总结自互联网技术社区（如CSDN、博客园、掘金等）普遍讨论的缓存穿透解决方案，以及Redis官方文档中关于缓存模式的相关建议。