1. 引言双十一零点刚过，某电商平台的商品详情接口流量瞬间飙升。用户疯狂点击、刷新，大量请求涌向 Redis 缓存——但其中相当一部分 key 是数据库中根本不存在的商品 ID（如被下架的商品、被恶意构造的无效 ID）。由于缓存中没有这些 key，请求层层穿透，直接打到 MySQL 数据库。短短几分钟，数据库连接池被耗尽、慢查询堆积、CPU 飙升至 100%，最终数据库宕机，整站瘫痪。这就是典型的缓存穿透问题。在高并发、海量数据的业务场景下，如何快速判断一个元素是否存在于一个庞大的集合中，是开发者经常面临的挑战。例如：防止缓存穿透、过滤恶意 URL、判断用户是否阅读过某篇文章等。如果直接查询数据库或遍历集合，性能往往难以承受。Redis 提供的布隆过滤器（Bloom Filter）正是为解决这类问题而生。它用极小的内存开销，以“可能存在”或“一定不存在”的判定结果，大幅提升系统吞吐量。回到上面的电商场景：只需在缓存前加一道布隆过滤器，把所有真实存在的商品 ID预先写入其中。当请求到来时，先问过滤器“这个商品 ID 存在吗？”——若回答“不存在”，则一定不存在，直接返回空结果，根本不会打到数据库；只有回答“可能存在”的请求，才继续走缓存 → 数据库的常规链路。这样，绝大多数无效请求在入口处就被拦截，数据库得以安稳度过大促高峰。本文将带你从使用场景出发，逐步深入布隆过滤器的核心原理，并给出基于 Redis 的实战示例。2. 布隆过滤器是什么布隆过滤器是一种空间效率极高的概率型数据结构，由 Burton Howard Bloom 于 1970 年提出。它的本质是一个位数组（bit array）配合多个哈希函数，用于判断一个元素是否在集合中。它的判定结果有两个特点：如果布隆过滤器说“不存在”，那么元素一定不存在；如果布隆过滤器说“存在”，那么元素可能存在（存在一定的误判率）。这种“宁可信其有，不可信其无”的特性，使其非常适合作为系统的前置过滤层。3. 典型使用场景3.1 解决缓存穿透缓存穿透是指查询一个数据库中不存在的数据。由于缓存中没有，请求会直接打到数据库，当恶意攻击者频繁构造不存在的 key 时，数据库压力会急剧增大。在 Redis 缓存前增加布隆过滤器，将所有可能存在的数据 key 预先写入过滤器。当请求到来时：先查询布隆过滤器；若判定 key 不存在，直接返回空结果，不再查询数据库；若判定 key 可能存在，再走缓存 → 数据库的常规链路。这样，绝大多数无效请求在入口处就被拦截，数据库得以保护。下面是请求经过布隆过滤器、缓存与数据库的完整判断流程：不存在可能存在缓存命中缓存未命中存在不存在客户端发起请求查询布隆过滤器直接返回空结果查询 Redis 缓存返回缓存数据查询数据库数据库中是否存在回写缓存并返回数据
