引言
在我们的一条推荐流水线中，有一个简单的需求，那就是不能向用户展示他们已经浏览过的文章。在流量峰值时，Feed 服务每秒处理约 18000 个请求，每个请求需要评估约 120 个候选内容。这意味着每秒需要执行约 216 万次检查。然而，该工作负载分布极不均匀，大约 97%-98%的检查结果都是用户未浏览。
我们最初的设计是对每个候选内容执行精确查询（缓存 + 后端存储）。该方案功能上可行，但是在大量查询结果都是否定结果的项目中效率较低。每次未命中仍然会产生网络与存储开销，导致 I/O 上升。在流量高峰期，这表现为 p95 延迟升高（从约 85ms 升至 140ms）、后端读取请求激增，以及基础设施成本持续上涨。
为了解决该问题，我们在精确查询路径前引入了布隆过滤器（Bloom filter）。过滤器在内存中能够直接排除确定不存在的项目，只将可能存在的项目提交给高开销的验证流程。这一改动让我们避免了对确定不存在的项目执行无效操作，同时降低了延迟与后端负载。通过提前过滤确定的未命中项，我们可以将资源集中在真正需要验证的场景上。
本文将完整讲解该实现方案，涵盖了架构问题、布隆过滤器的原理、Go 语言集成、带数学计算的参数调优（m 和 k），以及在生产环境约束下落地该方案的实践经验。
原始方案：对每个候选内容执行精确查询
如前文所述，在引入布隆过滤器前，我们的推荐服务采用基础的“精确查询优先（exact-first）”架构：
在候选内容生成阶段，生成经过一个有序的候选文章 ID 的列表
在历史检查阶段，逐个校验候选内容是否在用户的已浏览集合中
历史检查采用缓存优先的逻辑，未命中时查询后端存储
仅通过校验的未浏览候选内容会进入最终排序与响应组装
从准确性角度来看，这个方案十分理想：去重逻辑确定性强，易于理解。但从系统角度来看，该阶段处于服务关键路径上，每个候选内容都要执行一次远程成员检查。
为何仅靠精确查询无法满足需求
业务负载本身的特点导致该方案从设计上就存在高开销的问题。约 97%-98%的检查结果为未浏览，意味着绝大多数查询仅用于返回“未浏览”这样一个结果并继续流程。换言之，我们主要为否定结果承担存储与网络的开销。
在流量峰值下，有三个问题尤为突出：
延迟放大：单次请求包含大量候选检查，p95 响应延迟从约 85ms 提升至 140ms。
读取放大：后端与缓存读取量随单个请求的候选检查数（“候选扇出”）而增长，而非仅随请求数增长。
成本压力：基础设施成本随流量上涨，因为精确查询占据了核心服务路径。
此时我们需要一种新的设计，在保证关键场景准确性的前提下，在以否定结果为主的路径中，移除绝大多数不必要的高开销查询。
解决方案：布隆过滤器
优化方案是在执行高开销的历史查询前，引入布隆过滤器进行内存级快速检查（“成员网关”）。简单来说，布隆过滤器（Bloom filter）是一种紧凑的概率型数据结构，专门用于成员检查。它使用位数组（bit array）存储信息，并为每个键应用多个哈希函数。查询仅会有两种结果：
绝对不存在（结果 100%正确）
可能存在（这个结果可能会存在误判）
它永远不会产生假阴性的结果，非常适合快速排除确实未浏览的内容。
引入布隆过滤器后，请求流程调整为：
生成候选文章的 ID 列表
使用(user_id, article_id)组合键查询布隆过滤器
如果过滤器返回绝对不存在，直接判定为未浏览，保留在排序流水线中
如果过滤器返回可能存在，继续执行精确的历史校验
这一设计正好命中了上一节的核心痛点：以否定结果为主的路径。由于大多数候选内容都是未浏览，所以
绝大部分检查都可以在内存中完成，无需远程 I/O。
为什么概率型方法适合该负载
这里介绍的方法具备几个很有价值的特性：
否定结果占比极高：在约 97%-98%为否定结果的分布场景中，快速拒绝否定结果的收益非常高
在需要的地方保持严格的正确性：正向结果仍然可以通过精确存储进行校验
内存占用可预测：布隆过滤器可以紧凑地表示大规模的成员集
可调节的权衡：正如后文所示，我们可通过 m(位数组大小)和 k(哈希函数个数)控制误报率
在接下来的章节中，我们将介绍布隆过滤器如何运行、如何在 Go 中实现它，以及如何用数学方法为该推荐系统的场景完成参数调优。
布隆过滤器实践
在我们的推荐工作负载中，布隆过滤器的目标是快速识别大概率未浏览的候选项，避免不必要的高开销历史查询。由于大多数候选检查都是否定的结果，过滤器可以从服务路径中移除大量可避免的存储和网络开销。
核心机制
布隆过滤器会为元素集合编码其成员的信息。它的核心组件简单而高效：
布隆过滤器并不存储元素本身，而只在位数组上编码“是否出现过”的信息。
插入操作
要把元素 E 加入布隆过滤器：
对 E 应用 k 个哈希函数：h1(E), h2(E),…,hk(E)均会生成一个数字化的哈希值。
通过对 m 取模把哈希值映射到位数组中：indexi=hi(E) mod m 这样会得到位数组中的 k 个位置(由于冲突，某些位置可能相同)。
把这些位置上的位设置为 1：bit_array[index_i]=1
多个元素可能会设置位数组中想通的位值。位值只会被置位，不会被清零，这也是标准布隆表达式不支持删除的原因。
成员查询
当判断一个元素是否存在时：:
先为该元素计算相同的 k 个哈希值。
再检查位数组中对应位置的位值。
如果任意一个位值为 0，那么该元素就一定不在集合中，因为如果它被插入过，该位必然会被置为 1。
如果所有的位值都为 1，该元素就“可能在集合中”。这也是可能产生误报的地方：不同元素可能映射到同一组位置，导致即使查询元素从未加入过，对应的位值也可能均已经被置位。
图 1 布隆过滤器的插入与成员校验
在上图中，我们把 3 个元素(element1、element2 和 element3)通过 2 个哈希函数(h1 和 h2)插入到布隆过滤器中。每个元素会在位数组中设置两个位值。当我们查询 element4 时，发现它对应的位值没有全部被置位，因此可以确定它不存在。(注意，图中存在哈希冲突：例如 element1 和 element3 都设置了 index 6 上的位值，这也是可能造成误报的原因所在。)
关键特性
布隆过滤器具备以下关键特性：
无假阴性：判定为“不存在”的结果始终正确。
可能出现误报：元素即使从未加入，也可能看起来是“存在的”。
确定性：同一个元素总会映射到同一组位值上。
内存和速度效率高：位数组与简单哈希计算支持快速插入和查询。
仅存储成员信息：无法反查原始元素。
不支持删除：位值一旦置位，无法在不影响其他元素的前提下清零。这是标准布隆过滤器的基础限制；虽然存在支持删除的变体(比如，计数布隆过滤器)，但会引入额外复杂性与内存开销。
虽然上述机制解释了布隆过滤器是“如何工作的”，但是，单纯理解其原理并不能确保能够得到可直接用于生产环境的过滤器。如果不谨慎选择位数组大小(m)、哈希函数数量(k)和具体的哈希函数，布隆过滤器可能效率低下或产生过多的误报。下一节我们会演示如何在 Go 中实现布隆过滤器，把机制落地成可运行的代码，关于如何选择和优化参数则放到了“实践注意事项与最佳实践”章节进行讨论。
在 Go 中实现布隆过滤器
Go 非常适合实现布隆过滤器，因为它提供了对内存的低层控制、高效的 slice 和数组，以及快速且可预测的执行表现。这些特性让我们更容易推导位数组、哈希计算和过滤器的整体性能，它们对于同时追求速度与内存效率的生产系统非常关键。
将布隆过滤器机制翻译成 Go 代码并不复杂。在实现上，需要使用位数组和多个哈希函数，它们对应了我们在核心机制小节中所描述的逐步执行的行为。在这一阶段，我们先关注结构和基础操作；参数调优会在“实践注意事项与最佳实践”章节展开。
定义布隆过滤器的结构
Go 中的布隆过滤器结构(struct)包含压缩位数组、可寻址的位值总数，以及配置好的哈希函数。把哈希函数存放在struct中可以避免每次调用时的 API 误用，也能让使用方式更友好。与每个位值存一个布尔值相比，采用压缩表述(每 word 64bit)可显著改善内存效率和缓存行为：
type BloomFilter struct { bits []uint64 // packed bit array (64 bits per word) m uint hashes []func([]byte) uint }
复制代码
创建新的布隆过滤器
NewBloomFilter函数用于按指定大小和哈希函数来初始化布隆过滤器：
// NewBloomFilter creates a new Bloom filter with m bits and configured hash functions.func NewBloomFilter(m uint, hashes []func([]byte) uint) *BloomFilter { if m == 0 { panic("bloom filter size m must be > 0") } if len(hashes) == 0 { panic("at least one hash function is required") } words := (m + 63) / 64 // ceil(m/64) return &BloomFilter{ bits: make([]uint64, words), m: m, hashes: hashes, }}
复制代码
为了操作压缩位数组，我们提供了设置和读取单个位值的辅助方法：
func (bf *BloomFilter) setBit(i uint) { word := i >> 6 offset := i & 63 bf.bits[word] |= uint64(1) << offset}func (bf *BloomFilter) hasBit(i uint) bool { word := i >> 6 offset := i & 63 return (bf.bits[word] & (uint64(1) << offset)) != 0}
复制代码
添加元素
Add方法接收一个 byte 切片(待加入的数据)，计算配置好的哈希值，映射到位数组索引后并设置对应的位值：
func (bf *BloomFilter) Add(data []byte) { for _, hash := range bf.hashes { idx := hash(data) % bf.m bf.setBit(idx) }}
复制代码
位值只会被置位，插入逻辑与布隆过滤器核心机制完全一致。
查询元素
Contains方法通过检查哈希值对应的位值，判断元素是否“可能存在于”布隆过滤器中：
func (bf *BloomFilter) Contains(data []byte) bool { for _, hash := range bf.hashes { idx := hash(data) % bf.m if !bf.hasBit(idx) { return false } } return true }
复制代码
该方法只要发现任意一个位值未置位就返回 false，因此不会产生假阴性；如果所有位值均为 1 则返回 true，表示“可能存在”(仍然有误报的可能性)。
这个实现完整对应了前文所述的核心机制实现：多个独立哈希、位数组更新和成员检查。下面给出了一个可运行的示例，展示如何定义哈希函数并用样例数据测试过滤器：
package mainimport ( "Fmt" "hash/fnv")// Simple hash functionsfunc hash1(data []byte) uint { h := fnv.New32a() h.Write(data) return uint(h.Sum32())}func hash2(data []byte) uint { h := fnv.New32() h.Write(data) return uint(h.Sum32())}func main() { // Define hash functions hashes := []func([]byte) uint{hash1, hash2} bf := NewBloomFilter(20, hashes) bf.Add([]byte("apple")) bf.Add([]byte("banana")) bf.Add([]byte("cherry")) tests := []string{"apple", "banana", "cherry", "date", "fig"} for _, t := range tests { if bf.Contains([]byte(t)) { fmt.Printf("%s: possibly present\n", t) } else { fmt.Printf("%s: definitely not present\n", t) } }
复制代码
在这个示例中，我们基于FNV算法定义了两个简单的哈希函数。这样的函数用于演示已经足够了，但是生产系统通常会偏好质量更高的非加密哈希(例如，Murmur3、xxHash、MetroHash或HighwayHash)，并且要在真实 key 集合下验证其分布表现。定义好两个哈希函数后，我们创建了一个 20 bit、2 个哈希函数的布隆过滤器，加入 3 种水果，然后测试它们和另外 2 个未加入水果的是否存在。输出会显示哪些水果“可能存在”(可能误报)，哪些“确定不存在”：
apple: possibly presentbanana: possibly presentcherry: possibly presentdate: definitely not presentfig: definitely not present
复制代码
布隆过滤器背后的数学原理
布隆过滤器实现起来不难，但想要“用好”它并不简单：我们需要理解它的概率行为，才能真正发挥它的价值。这使工程师能够预测误报率，并在内存使用与哈希函数数量上做出有依据的选择，以达到目标误报率。布隆过滤器背后的数学原理对于调优参数(m、k 和哈希函数)至关重要，能帮助我们在内存效率与准确性之间找到平衡。
下面，我们先快速总结实践中最常用的关键公式。如果需要更深入的推导与理论背景，可查看深入知识的附录：布隆过滤器背后的数学原理。
误报率(p)大致等于:
$$p = \left(1 - e^{-\frac{kn}{m}}\right)^k$$
哈希函数的最优数量(k)：
$$k = \frac{m}{n}\ln 2$$
在目标误报率下所需的位数组大小(m)：
$$m = -\frac{n\ln p}{(\ln 2)^2}$$
结果速览
在推荐路径中引入布隆过滤器网关，并基于上述公式调优 m 和 K 后，我们在流量峰值窗口观察到三个稳定的结果：
尾延迟（tail latency）更低：Feed 的 p95 延迟从约 140ms 降至约 96ms(大约下降了 31%)。
高开销检查更少：精确历史查询从每请求约 120 次降至平均约 24 次(大约下降了 80%)。
后端压力更低：历史存储的读取流量下降了约 65%-70%，同时测得布隆过滤器误报导致的过度过滤保持在约 0.5%以内。
这些数字与具体负载有关，但模式具有普适性：当查询以否定结果为主且代价高昂时，调优得当的布隆过滤器可以消除大量可避免的后端工作。
实践注意事项与最佳实践
在该机制实现完成，并掌握如何用数学选择 k 与 m 之后，我们就可以把理论转化为工程决策。
先从产品约束出发，而不是先看布隆过滤器的参数
对我们的推荐路径来说，产品层面的问题不是“该使用什么值的 k 与 m？”，而是：
可接受多少重复推荐
服务层可投入多少内存
每个候选过滤还剩多少延迟预算
这让我们得到了明确的调优目标：
这是通用的原则：先从服务 SLO 和用户影响容忍度出发，再反推布隆过滤器的参数。
我们的场景中如何选择 n、m 和 k
在实现中，我们将 n 建模为一个过滤器在其生命周期窗口内所代表的预期已浏览条目的数量(例如，按用户滚动窗口统计)。
$$m \approx -\dfrac{n\ln P}{(\ln 2)^2},\quad k \approx \dfrac{m}{n}\ln 2$$
随后我们做了三项工程化的调整：
对 n 要预留增长余量：按增长规模而非当前均值确定容量，避免过早饱和。
为实现效率对 m 取整：为匹配压缩[]uint64 存储，按 word 边界取整。
为控制 CPU 成本限制 k：把计算值作为起点，再选取能让每个请求哈希计算保持在预算内的值(哈希本身的代价可能比较昂贵)。
在实践中，这意味着我们会接受略高的内存来保障业务增长场景下的误报，同时避免过大的 k 拖慢热点路径的延迟。
在这个具体推荐场景中，我们还做了一个重要服务决策：当误报率处于产品容忍范围内时，布隆过滤器为“可能存在”的结果并不总是会继续执行精确查询。小幅误报意味着偶尔会漏过一条未浏览内容，这在我们的 Feed 质量目标下是可接受的，而跳过精确校验会进一步减少后端成本和延迟。该做法适用于我们这个场景，但许多系统仍需要更严格保证。
该方式之所以可行，是因为偶发遗漏在我们的业务中是可接受的；但在很多系统里，仍然必须提供更严格保障的。一般来说，当误报代价高或正确性至关重要时，布隆过滤器命中的结果必须做精确验证；只有当产品行为能够容忍少量过度过滤时，才可选择性地略过。
哈希函数选择：先正确性，再吞吐量
在本文中，哈希值按照确定性的方式来生成的，并通过对 m 取模实现映射。一个关键的生产经验是，哈希策略绝非“无关轻重的细节”：
分布不佳会放大冲突
冲突会放大误报
误报会提高精确查询透传率
透传率升高会侵蚀布隆过滤器的收益
在各类布隆过滤器部署中都存在一个通用的权衡：完全独立的哈希族在服务系统中很少使用，因为 CPU 开销较高。更常见做法是双重哈希(由两个基础哈希推导 k 个索引)，通常能在保持良好分布的同时降低计算成本。
我们验证有效的做法包括：
跨实例保持确定且稳定的哈希行为
服务路径使用快速非加密哈希以保障性能
在代表性 key 集下做误报行为的实证验证
总体建议是：把哈希质量当作“可测量的指标”，而不是默认成立的假设。
监控正确的运行指标
一个布隆过滤器看起来“逻辑正确”，但在运行时仍可能“效果堪忧”。我们跟踪了如下指标：
这些指标适用于几乎所有生产布隆过滤器部署，它们能告诉你过滤器是在持续节省成本，还是已经退化成额外开销的。
生命周期策略与初始调优同样重要
即便初始参数很好，只要基数增长超出假设，过滤器仍会退化。在我们的场景中，尽早定义生命周期策略非常关键，需要明确：
这些策略放到推荐系统之外的一般场景同样成立：如果数据是动态且持续增长的，就不能依赖“一次性配置”的过滤器。你需要明确生命周期策略，包括何时重建、何时轮转，以及如何处理突发增长。否则，过滤器准确性和效率会随时间持续退化。
实践检查清单
在高吞吐系统中上线布隆过滤器前，请先检查：
从产品角度定义可接受的误报影响
在估算 n 时预留增长余量
先计算 m 和 k，再结合延迟与内存预算调优
用真实 key 分布验证哈希行为
埋点透传率与饱和度指标
预先制定重建/轮转策略
按这种方式使用时，布隆过滤器会是高投资回报比的优化手段，而不是脆弱的“微优化技巧”。
结论
布隆过滤器解决的是我们真正的问题：在否定结果占主导的路径上，“是否已浏览”检查太多且太贵。通过把成员过滤前置到内存中，我们从 Feed 关键路径中移除了大量可避免 I/O，在不显著增加内存占用的前提下重新获得了延迟余量。
核心经验并不是“永远使用布隆过滤器”，而是把它当作可调的系统组件：根据产品容忍度和流量形态设定 m 与 k，同时兼顾分布质量和吞吐来选择哈希函数，并在价值被悄然侵蚀前监控饱和度。
在推荐过滤这类可容忍低频误报的场景中，布隆过滤器不只是教科书概念，它可以成为真正可用于生产的性能和成本优化杠杆。
深入知识的附录：布隆过滤器背后的数学原理
如果你对这些结果背后的数学细节感兴趣，下面给出完整推导与解释。
为什么会出现误报
要理解误报何时发生，先回顾以下事实：
当某个查询元素虽然从未插入，但其 k 个哈希位都恰好已被其他元素置位时，就会发生误报。
单个位值仍为 0 的概率
如前所述，布隆过滤器行为由三个参数决定：
m=位数组位值的总数
k=哈希函数个数
n=已插入元素数量
插入一个元素时，每个哈希会设置一个位值。某个特定位在一次插入后仍为 0 的概率是：
$$p_0 = 1 - \frac{1}{m}$$
插入 n 个元素、每个元素使用 k 个哈希后，某位值仍为 0 的概率为：
$$p_0 = \left(1 - \frac{1}{m}\right)^{kn}$$
当 m 足够大时，近似形式为：
$$\left(1 - \frac{1}{m}\right)^{kn} \approx e^{-\frac{kn}{m}}$$
该近似能得到更简洁的误报分析公式。
误报的概率
如果某个查询元素对应的 k 个位值全为 1，则形成误报。基于前述结果可得：
$$P_{fp} = (1-p_0)^k \approx \left(1 - e^{-\frac{kn}{m}}\right)^k$$
如何选择 m 和 k
这些公式可用于计算工程上可落地的参数：
$$m \approx -\dfrac{n\ln P}{(\ln 2)^2},\quad k \approx \dfrac{m}{n}\ln 2$$
随着饱和度升高(位数组置位的比例接近 1)，误报率也会逼近 1，这就是为什么容量规划和生命周期策略都非常关键。
如果缺少这类分析，布隆过滤器要么误报率过高，要么浪费内存(甚至可能难以及时察觉)。理解这些数学原理，是在真实业务中正确配置布隆过滤器并有效管理权衡的基础。
原文链接：
Bloom Filters: Theory, Engineering Trade‑offs, and Implementation in Go
