布隆过滤器在 Redis 中的核心作用是快速判断一个元素是否可能存在于集合中，它不存储元素本身，因此可以用极小的内存处理海量数据。但代价是存在误判：查询返回存在时，元素可能并不在集合里。误判率设置直接影响内存开销和结果可信度，如果设置过高，过滤效果形同虚设；如果设置过低，内存会急剧膨胀。要合理配置误判率，需要先理解其数学原理，再通过 RedisBloom 模块的参数落到实践。
误判率的数学本质：m、k、n 如何决定假阳性概率
布隆过滤器由一个长度为 m 的位数组和 k 个独立的哈希函数构成。插入元素时，用 k 个哈希函数分别计算位置，将这些位置置为 1；查询时同样计算 k 个位置，只要有一个位置为 0，元素一定不存在；如果全部为 1，则元素可能存在，也可能因为其他元素插入了这些位置而产生误判。
假设已经插入了 n 个元素，某个位在插入过程中没有被置为 1 的概率是 (1 - 1/m)^{kn}。当 m 较大时，这个值近似为 e^{-kn/m}。因此一个位被置为 1 的概率约为 1 - e^{-kn/m}。查询一个不存在的元素时，它必须恰好命中 k 个已经被置为 1 的位，所以误判率 p 可以表示为：
p ≈ (1 - e^{-kn/m})^k
该公式说明误判率由三个参数共同决定。对于固定的 m 和 n，可以求出使 p 最小的 k 值：k = (m/n) * ln2。此时误判率约等于 (0.6185)^{m/n}。也就是说，每个元素占用的位数 m/n 越多，误判率呈指数级下降。例如每个元素分配 10 个比特位时，理论误判率约为 0.00819；分配 15 个比特位时，误判率降至约 0.000742。这也解释了为什么误判率设置越低，位数组长度 m 就需要越大，内存占用随之增加。
需要注意的是，这里的 n 是预期插入的元素数量，而不是当前实际数量。如果实际插入数量远超过预估值，位数组中 1 的比例会显著上升，误判率会高于设定值。因此在使用 RedisBloom 时，capacity 参数应尽量准确，必要时预留一定冗余。
RedisBloom 中通过 BF.RESERVE 设置误判率与容量
RedisBloom 是 Redis 的官方布隆过滤器模块，它封装了复杂的参数计算。创建过滤器时使用 BF.RESERVE 命令，语法如下：
BF.RESERVE user_filter 0.01 1000000
这条命令创建了一个名为 user_filter 的布隆过滤器，期望误判率为 0.01，容量为 1000000 个元素。RedisBloom 会根据这两个参数自动计算位数组长度 m 和哈希函数个数 k，无需开发者手动干预。error_rate 的取值范围通常在 0 到 1 之间，值越小误判率越低，但内存占用越大；capacity 表示预计要插入的元素数量，它直接影响位数组大小。
如果业务数据量可能动态增长，可以使用可扩展布隆过滤器。BF.RESERVE 支持 EXPANSION 参数：
BF.RESERVE scalable_filter 0.001 10000 EXPANSION 2
当实际元素数量超过初始容量时，RedisBloom 会自动创建一个新的子过滤器。EXPANSION 参数指定每次扩展时新子过滤器的容量增长倍数，默认值为 2。需要注意的是，扩展后的整体误判率会略高于初始设置的误判率，因为多个子过滤器叠加后假阳性概率会累积。如果对误判率要求严格，建议初始容量设置得足够大，避免频繁扩展。
创建过滤器后，可以使用 BF.ADD 插入元素，使用 BF.EXISTS 查询元素：
BF.ADD user_filter user:10086 BF.EXISTS user_filter user:10086 BF.EXISTS user_filter user:99999
查询已插入的元素时返回 1，查询可能不存在的元素时，可能返回 0 或 1。如果返回 1，但元素实际上从未插入过，就发生了误判。通过调整 error_rate，可以控制这种误判出现的概率。
误判率设置实践：内存估算与参数调优
要选择合理的误判率，需要清楚不同参数对应的内存开销。位数组长度 m 可以通过公式 m = - (n * ln p) / (ln 2)^2 估算，其中 p 是目标误判率，n 是元素数量。得到 m 后除以 8 即为字节数。例如容量为 100 万，误判率 0.01 时，m 约为 9585058 比特，约 1.14 MB；误判率降到 0.001 时，m 约为 14377588 比特，约 1.71 MB；进一步降到 0.0001 时，m 约为 19170116 比特，约 2.29 MB。可以看到，误判率每降低一个数量级，内存增加约 20% 到 50%，但并非线性增长。
下表列出了容量为 100 万时不同误判率的大致内存占用和理论哈希函数个数：
| 目标误判率 | 每元素位数 m/n | 内存占用（约） | 哈希函数个数 k |
|---|---|---|---|
| 0.1 | 4.79 | 0.57 MB | 3 |
| 0.01 | 9.59 | 1.14 MB | 7 |
| 0.001 | 14.38 | 1.71 MB | 10 |
| 0.0001 | 19.17 | 2.29 MB | 13 |
实际业务中，如果使用 RedisBloom，无需手动计算哈希函数个数，模块会自动选取最优值。但如果基于原生 Redis 的 SETBIT 和 GETBIT 命令自行实现布隆过滤器，就必须手动计算 m 和 k。以下 Python 示例展示了如何根据误判率和容量计算 m 与 k：
import math
def bloom_params(n, p):
m = - (n * math.log(p)) / (math.log(2) ** 2)
k = (m / n) * math.log(2)
return int(m), int(k)
n = 1000000
p = 0.01
m, k = bloom_params(n, p)
print(f"m={m}, k={k}")
运行输出 m=9585058, k=7。这与 RedisBloom 内部的计算结果基本一致。自行实现时，哈希函数可以使用双重哈希或多次哈希技巧，例如使用 MurmurHash 计算两个基础哈希值，然后通过 h_i = h1 + i * h2 生成 k 个哈希位置。
误判率设置的常见误区是盲目追求极低的假阳性。例如在缓存穿透场景中，将误判率设为 0.000001 虽然可以更精确地拦截不存在的 key，但内存占用会大幅增加。如果数据量达到亿级，每元素 19 比特与每元素 10 比特之间的内存差距可能高达数百 MB。实际上，缓存穿透防护只需要把绝大多数不存在的请求拦在数据库之外，0.01 的误判率已经足够，少量误判请求打到底层数据库并不会造成致命压力。相反，在去重场景中，如果误判导致重复数据被丢弃，业务影响较大，可以适当降低误判率，例如 0.001 或 0.0001，但依然要评估内存成本。
监控与调整：BF.INFO 查看过滤器状态
布隆过滤器在创建后，其误判率参数通常无法直接修改。如果想改变误判率，需要重新创建一个新的过滤器，并将历史数据重新插入。为了避免这种繁琐操作，建议在创建时充分评估业务容量和误判率需求，预留一定扩展空间。对于可扩展布隆过滤器，虽然可以自动扩容，但整体误判率会随子过滤器数量增加而变化，因此也不能在运行中单独调整某一层的误判率。
RedisBloom 提供了 BF.INFO 命令查看过滤器的详细信息：
BF.INFO user_filter
输出示例如下：
Capacity: 1000000 Size: 1198132 Number of inserted items: 500000 Number of filters: 1 Expansion rate: 2
通过 Size 字段可以了解实际分配的字节数，结合 Capacity 和插入数量可以判断当前误判率是否偏离设定值。如果插入数量已经接近或超过 Capacity，过滤器的误判率会明显上升，此时应考虑扩容或重新创建。BF.INFO 还可以返回 Number of filters，用于确认可扩展过滤器是否已经触发扩展。
总结来说，Redis BloomFilter 的误判率设置需要从数学公式出发，理解 m、k、n 三者关系，再通过 RedisBloom 的 BF.RESERVE 命令将 error_rate 和 capacity 映射为底层位数组和哈希函数。实践中最重要的是在准确性和内存成本之间找到平衡，同时监控实际插入数量，防止误判率失控。
Redis BloomFilter误判率哈希函数修改时间：2026-08-26 01:37:45