Go bloom 怎样把字符串加入过滤器并查询

我在做字符串去重预筛选时，先把原来的 map[string]struct{} 换成了 Go bloom 的过滤器。真正需要记住的写法只有两组：用 AddString 加入字符串，用 TestString 查询字符串。

官方地址：https://pkg.go.dev/github.com/bits-and-blooms/bloom/v3

不过它不是精确集合：查询结果为 false 时可以确定字符串没有加入；结果为 true 时，只能说“可能加入过”，仍可能遇到误判。下面按我从字节切片写法迁到字符串写法时的顺序，把容量、调用和边界一次说明白。

结论：先用 NewWithEstimates 设定预计数量和目标误判率，再调用 AddString 与 TestString。布隆过滤器只适合做快速预筛选，不能替代保存原始字符串的精确存储。

先把旧的字节写法迁到字符串方法

bloom/v3 的底层接口接受 []byte，所以早期示例通常会把字符串显式转换。迁移到字符串专用方法后，意图更清楚，也少了一次手写转换：

package main

import (
    "fmt"

    "github.com/bits-and-blooms/bloom/v3"
)

func main() {
    // 预计保存 100000 个字符串，目标误判率设为 1%。
    filter := bloom.NewWithEstimates(100000, 0.01)

    // AddString 只记录位图信息，不保存原始字符串内容。
    filter.AddString("order:20261031")

    // TestString 返回 false 表示一定不存在，true 表示可能存在。
    fmt.Println(filter.TestString("order:20261031"))
    fmt.Println(filter.TestString("order:20261032"))
}

如果你已经有 []byte，Add 和 Test 仍然可用；只是处理字符串时，AddString 与 TestString 更不容易把编码转换散落在业务代码里。

容量和误判率决定迁移后的代价

我第一次迁移时只改了 API，却没有重新估算容量，结果是数据量接近上限后，查询到“可能存在”的字符串变多。NewWithEstimates(n, fp) 的第一个参数是预计元素数，第二个参数是期望的 false positive rate。目标误判率越低，通常需要更多内存；预计容量也不能故意写得过小。

// 用业务上限而不是今天的瞬时数量估算容量。
expected := uint(500000)
targetFP := 0.005
filter := bloom.NewWithEstimates(expected, targetFP)

// Cap 和 K 可用于记录当前过滤器的参数，便于排查配置差异。
fmt.Println("bits:", filter.Cap())
fmt.Println("hashes:", filter.K())

这里的 true 不是命中证明。实际业务通常还要在过滤器后面接数据库、缓存或精确的 map：过滤器返回 false 可以直接短路，返回 true 再访问精确数据源。

把查询放在精确存储之前

布隆过滤器最适合做“先挡掉肯定不存在的请求”。例如检查订单号时，先查询 TestString，只有可能存在才继续访问精确存储：

func mayHaveOrder(filter *bloom.BloomFilter, exact map[string]struct{}, id string) bool {
    // false 是确定不存在，可以避免一次精确存储查询。
    if !filter.TestString(id) {
        return false
    }

    // true 可能是误判，所以仍要回到精确集合确认。
    _, ok := exact[id]
    return ok
}

func addOrder(filter *bloom.BloomFilter, exact map[string]struct{}, id string) {
    // 先写入过滤器，再写入精确集合；两者承担不同职责。
    filter.AddString(id)
    exact[id] = struct{}{}
}

顺序可以按业务一致性要求调整，但不能省略精确确认。过滤器不会返回“确定不存在但实际存在”的假阴性；它的风险集中在假阳性，也就是多做了一次后续查询。

迁移清单：并发、生命周期和误判说明

官方文档明确提示，同一个过滤器在多个 goroutine 中并发访问并不安全；如果有写入或其他修改，应由 channel 或 sync.Mutex 串行化。只有在确认所有并发操作都不会修改内容时，才适合共享只读访问。

type SafeFilter struct {
    mu sync.RWMutex
    f  *bloom.BloomFilter
}

func (s *SafeFilter) Add(value string) {
    // 写入会改变位图，使用写锁保护 AddString。
    s.mu.Lock()
    defer s.mu.Unlock()
    s.f.AddString(value)
}

func (s *SafeFilter) Test(value string) bool {
    // 查询不修改过滤器，读锁允许多个查询并行。
    s.mu.RLock()
    defer s.mu.RUnlock()
    return s.f.TestString(value)
}

上线前我会保留一张迁移清单：

• 预计元素数按峰值或生命周期上限估算，而不是按当前样本数估算。
• 记录目标误判率，并接受低误判率带来的内存成本。
• 把 true 定义为“可能存在”，后面保留精确存储确认。
• 明确过滤器是否需要重建；它不是会自动扩容的动态精确集合。
• 所有会修改过滤器的并发路径都通过统一同步边界。

常见问题

TestString 返回 false 能不能只是暂时没查到？

在过滤器状态和查询输入一致的前提下，false 表示这些位没有全部被设置，因此可以判断该字符串不在集合中。

为什么 TestString 返回 true 还要查数据库？

因为布隆过滤器允许 false positive。true 只能说明位图模式匹配，不能证明原始字符串确实存在。

可以直接把 bloom 当作字符串集合保存吗？

不可以。它只保存位图，不保存原始字符串，也不提供精确枚举能力；需要精确结果时必须保留其他存储。