Bloom Filter 不能单独用于消息去重，因其存在误判率；必须配合 Redis 的 SET 或 ZSET 做最终校验：SET 适用于简单幂等场景，ZSET 支持滑动窗口限频，典型流程为 Bloom Filter 预筛→Redis 精确判定→三重写入。
Redis 原生的 PUB/SUB 不提供消息去重能力，所有订阅者都会无差别收到每一条 PUBLISH 消息。想靠它直接实现幂等消费，必须在业务层补足——Bloom Filter 是轻量级预筛手段，但不能单独用；Redis 缓存（如 SET 或 ZSET）才是落地关键。
为什么 Bloom Filter 不能 standalone 做去重
Bloom Filter 是概率型数据结构，存在误判率（false positive），但不会漏判（false negative）。这意味着：
-
bloom.exists(msg_id)返回 false → 该msg_id绝对没出现过，可安全处理 -
bloom.exists(msg_id)返回 true → 可能是真重复，也可能是误报，仍需二次确认
所以它只能当“快速拒收门”，不能当“最终判决书”。生产环境必须搭配 Redis 的确定性存储（比如 SET）做最终校验。
用 SET 实现简单可靠的消息 ID 去重
适用于消息体不大、ID 全局唯一、且去重窗口期明确的场景（如订单通知、工单分发）。核心逻辑就是：查 + 写原子判断。
- 用
SET存已消费的msg_id，key 命名为dedup:channel_name或带时间戳前缀（如dedup:order_notify:202604）便于清理 - 不要先
GET再SET—— 这有竞态，改用SISMEMBER+SADD组合 - 若消息量极大、内存敏感，可加 TTL：
EXPIRE dedup:channel_name 86400，但注意 TTL 不会自动随SADD刷新
Python 示例（使用 redis-py）：
def consume_message(redis_cli, channel, msg_id, payload):
key = f"dedup:{channel}"
# 原子判断并添加
if redis_cli.sismember(key, msg_id):
return False # 已存在，跳过
redis_cli.sadd(key, msg_id)
redis_cli.expire(key, 86400) # 每次都设 TTL（可选）
# ✅ 此时才执行业务逻辑
process(payload)
return True用 ZSET 支持滑动窗口去重（防刷/限频）
当需要“1 分钟内同 ID 消息只处理一次”，或消息含时间戳需按有效期裁剪时，ZSET 更合适。它把 msg_id 当 member，时间戳当 score。
- 插入：
ZADD dedup_zset {timestamp} {msg_id} - 清理过期项：
ZREMRANGEBYSCORE dedup_zset 0 {cutoff_timestamp} - 判断是否新消息：
ZSCORE dedup_zset {msg_id}为nil才处理
注意：ZSCORE 和 ZADD 非原子，高并发下建议封装成 Lua 脚本执行，避免两次网络往返引入竞态。
Bloom Filter + Redis 的典型协作流程
不是二选一，而是分层过滤：
- 第一层：本地或 Redis-Mod 的 Bloom Filter（如
BF.EXISTS bloom_key msg_id）快速拦截明显重复 - 第二层：命中 Bloom Filter 后，再查
SET或ZSET做精确判定 - 第三层：确认为新消息后，同步写入 Bloom Filter（扩容）、
SET（记录）、ZSET（打时间戳）
真正容易被忽略的是 Bloom Filter 的容量预估和扩容成本——一旦初始化 size 固定，后续 BF.RESERVE 无法动态扩容，超容会导致误判率飙升。线上务必根据日均消息量 × 去重周期预估，并留 20% 余量。
