布隆过滤器是大数据去重的高效前置筛子，以极小内存代价快速排除不存在数据，适用于缓存穿透防护、URL去重、推荐去重和黑名单过滤等场景。
布隆过滤器（Bloom Filter）不是万能的去重方案，但它在大数据场景下是极其实用的“前置筛子”——不保证100%准确，但能以极小内存代价，快速排除绝大多数不存在的数据，大幅降低后续真实去重或查询的压力。
适合布隆过滤器的典型去重场景
它不存原始数据，只标记“可能见过”，因此特别适用于以下几类问题：
- 缓存穿透防护：用户频繁查一个数据库里根本不存在的 key（比如恶意刷 ID=999999999），Redis 缓存没命中，请求直击数据库。加一层布隆过滤器，查询前先过一遍——若过滤器说“不存在”，直接返回空，不查 DB。
- 爬虫 URL 去重：亿级网页链接，只需知道某个 URL 是否已爬过。用布隆过滤器记录哈希指纹，内存仅需 GB 级，比存完整 URL 节省 95%+ 内存。
- 推荐/新闻流去重：对单个用户展示“未读内容”，需跳过其历史点击过的几千甚至上万条。布隆过滤器可为每个用户维护一个轻量集合，判断某篇文章 ID 是否已读，响应快、不拖慢刷新体验。
- 邮件或短信黑名单过滤：发信前快速判断发件人邮箱或手机号是否在数亿黑名单中。布隆过滤器支持毫秒级查询，且可水平扩展，适配实时风控链路。
为什么它能在大数据去重中省下大量资源
核心在于“只存位，不存值”：
- 传统 HashSet 存 10 亿个字符串（平均 50 字节），内存至少 50GB；布隆过滤器同等规模通常只需 1–2GB。
- 查询时间复杂度稳定为 O(k)，k 是哈希函数个数（通常 3–7），和数据总量无关。
- 允许可控误判（比如 0.1%～1% 的“可能存在”误报），但绝不会漏判——即“说不存在，就一定不存在”，这个确定性保障了下游系统安全。
使用时必须注意的关键点
布隆过滤器强大，但用错会引入隐患：
- 不支持删除：一旦某个元素被加入，无法从位数组中干净移除。如需动态剔除，得换 Counting Bloom Filter 或其他变体。
- 误判率要提前规划：它和位数组长度 m、哈希函数个数 k、预期元素总数 n 强相关。例如 10 亿数据 + 0.1% 误判率，m 约需 96 亿 bit（≈1.14GB），k ≈ 7。
- 不能替代最终校验：它只做“快速否定”，业务关键路径中，“可能存在”之后仍需查库或查存储确认真实存在性。
- 哈希函数需独立均匀：建议用 MurmurHash3、xxHash 等高质量哈希，避免因哈希偏差导致误判率飙升。
工程落地常见组合方式
单独用布隆过滤器较少，它常作为“第一道防线”嵌入整体架构：
- Redis + RedisBloom 模块：开箱即用，支持 add / exists / reserve 等命令，适合中小规模实时去重。
- 本地内存 + Guava BloomFilter：Java 服务内嵌，低延迟、无网络开销，适合高并发单机判别场景。
- HBase / Kafka + 分布式布隆过滤器：预生成全局过滤器文件（如 bitmap 文件），分发到各计算节点，用于离线 ETL 或流式作业去重。
- 与数据库协同：MySQL 8.0+ 支持 Bloom Filter 索引；PostgreSQL 9.6+ 引入 bloom 索引插件，加速大表 exists 查询。
