Redis缓存穿透防护中，布隆过滤器如何动态扩容？

Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容必须手动新建过滤器、迁移数据并切换key，参数选错易致内存激增或OOM。

Redis原生命令根本不支持动态扩容

BF.RESERVE 创建的布隆过滤器，capacity 和 error_rate 一旦设定就不可修改。这不是配置遗漏或权限问题，而是 RedisBloom 模块的设计限制——底层位数组长度固定，哈希函数数量也固化。你执行 BF.ADD 时发现误判率飙升、写入延迟变高，大概率不是代码写错，而是当前过滤器已严重超载。

扩容必须手动迁移，且不能靠 tryInit() 自动升级

Redisson 的 RBloomFilter.tryInit() 方法只在 key 不存在时生效；如果 myBloomFilter 已存在且初始容量是 1000，再调用 tryInit(2000, 0.01) 会静默失败，不会覆盖或扩容旧结构。

真实扩容流程必须人工介入：

1. 新建一个更大容量的过滤器，例如 redisson.getBloomFilter("myBloomFilter_v2")
2. 用 bloomFilter.count() 获取旧过滤器当前插入量，避免盲目全量重放（尤其当数据量达百万级时）
3. 逐条调用 add() 将旧数据迁移到新过滤器——注意：不能用 readAll()，布隆过滤器本身不存原始 key 值，无法遍历
4. 业务侧切换 key 名（如从 bf_user 改为 bf_user_v2），再执行 redisson.getBucket("bf_user").delete()

参数选错比不扩容更危险

error_rate 和 capacity 是强耦合关系。例如：

1. error_rate=0.03 时，位数组大小 m ≈ 15 × capacity
2. error_rate=0.001 时，m ≈ 24 × capacity

这意味着：把 capacity 从 1000 扩到 10000，若同时压低 error_rate 到 0.001，内存占用可能暴涨 24 倍，直接触发 OOM killer。线上环境慎用 error_rate ，尤其在大容量场景下。

实操建议：

1. 用 BF.INFO myBloomFilter 查 size（字节数）和 items（已插入数），计算填充率：items / capacity
2. 填充率 > 75% 就该预警；> 90% 时误判率会陡增——此时宁可接受 error_rate=0.05，也不要硬扛 0.01

绕过扩容的轻量级兜底方案

不想改 key、不写迁移逻辑，又得扛突发流量？这几个方案更贴近真实运维节奏：

1. 分片布隆：按 ID 哈希后路由到 bf_user_0 ~ bf_user_9 共 10 个过滤器，每个容量设为总预估量的 1/10，天然规避单点容量瓶颈
2. 双层校验：第一层用宽松 error_rate=0.1 快速过滤掉 90% 无效请求；对“可能存在”的请求再走一次 EXISTS 缓存查询，二次拦截剩余穿透
3. 降级开关：监控 BF.INFO 的 inserted 字段突增，自动切到 Redis SET 临时兜底（内存涨 10 倍，但保服务可用）

布隆过滤器的“动态”本质是运维动作，不是 API 能力。所有试图封装成“自动扩容”的 SDK，最终都会卡在数据一致性上——它连自己存了啥都不知道。