Redis BF.RESERVE怎么设置容量与误判率

我第一次给 Redis Bloom 配布隆过滤器时，最容易写错的不是命令拼法，而是把“允许多少误判”和“准备放多少条数据”混成一个数字。BF.RESERVE 的正确思路是：先定业务能接受的误判率，再按预计写入量设置容量，最后决定容量不够时是否允许继续扩展。

官方地址：https://redis.io/docs/latest/commands/bf.reserve/

BF.RESERVE 的三个必填参数怎么理解

命令的最小形式是 BF.RESERVE key error_rate capacity。key 是过滤器名；error_rate 是误判为“存在”的概率，取值是 0 到 1 之间的小数；capacity 是预期要加入的条目数。

# 为商品编号预留一个预计容纳 100 万条的过滤器
BF.RESERVE product:seen 0.001 1000000

这里的 0.001 代表 0.1%，不是把百分号写进命令。布隆过滤器允许“假阳性”：查询一个实际上没加入过的值时，可能回答它存在；但它不能用来证明“绝对不存在”。

capacity 应该按预计总量设置

capacity 不是“今天先放多少条”，而是这个过滤器在设计周期内预计要承载的条目数。官方文档说明，允许扩展的过滤器超过初始容量后会增加子过滤器；子过滤器越多，维护和查询成本越高。因此能估算总量时，直接把预计总量写进 capacity 往往更省心。

例如每日新增 8 万条、保留 30 天，容量不能只写 8 万；至少要先把 240 万条作为业务估算，再为突发增长留出余量。余量不是越大越好，因为误判率相同的前提下，容量变大就要占用更多位空间。

误判率越低，空间和哈希成本越高

官方给出的近似关系很适合做参数初筛：误判率为 1% 时约需 7 个哈希函数、每条约 9.585 bit；0.1% 时约需 10 个哈希函数、每条约 14.378 bit；0.01% 时约需 14 个哈希函数、每条约 19.170 bit。

所以我不会一上来就把误判率压到 0.01%。如果过滤器只是减少一次昂贵的详情查询，0.1% 可能已经足够；如果误判会触发高成本风控或人工流程，再考虑更低的误判率。最终要把误判带来的业务成本和额外内存、CPU 成本放在同一张账上。

EXPANSION 和 NONSCALING 怎么选

默认情况下，容量达到后 Redis 会创建新的子过滤器；新的子过滤器大小由上一个子过滤器乘以 expansion 决定，默认值是 2。数据量未知或增长波动明显时，保留默认扩展通常比较稳；如果数据规模可预测，EXPANSION 1 可以降低每次扩展的空间跳跃。

# 数据量不稳定：允许按默认扩展因子继续增加子过滤器
BF.RESERVE user:seen 0.001 1000000 EXPANSION 2

# 容量是硬边界：达到 100 万条后不再创建子过滤器
BF.RESERVE audit:seen 0.0001 1000000 NONSCALING

NONSCALING 适合容量必须可控、超限就应该显式暴露的场景。容量达到后命令会返回错误，而不是悄悄增加子过滤器。它的内存略低，但代价是业务方必须准备好扩容或新建过滤器的处理路径。

我现在会先写下这张参数清单

还要记住两点：同一个 key 不能重复执行 BF.RESERVE，已存在时会报错；误判率只影响“把不存在说成存在”的概率，不能把 Bloom Filter 当成精确集合。把这两个边界写进初始化和告警说明，后续排查会清楚很多。

相关问题

error_rate 能不能写成 0.1？

可以执行，但它表示 10% 的误判率，不是 0.1%。如果目标是 0.1%，应写成 0.001。

capacity 写小了会立刻失败吗？

默认可扩展配置通常会创建新的子过滤器，但多出来的子过滤器会增加维护和查询成本；使用 NONSCALING 时，达到容量后会返回错误。

什么时候适合用 NONSCALING？

当容量是明确的资源边界，超限必须被业务捕获，而不是接受 Redis 自动增长时使用。前提是应用已经设计好新建过滤器或分片的处理方式。