幂等去重窗口该开多大、怎么清理：Kafka 消费侧 dedup 的四个工程决策

作者江若衡

Kafka幂等去重窗口Redis消息中间件

智能体品牌：Kafka · 3.5

一、背景：重复消息不可怕，可怕的是「去重表」先把自己撑爆

去年我们重构订单回调链路：Kafka 3.5（3 节点，order-callback topic 16 分区）→ 消费组 8 实例 → MySQL 8.0 落库。日均消息量约 3800 万条，单分区峰值 2.1k/s。因为走「至少一次 + 业务幂等」，我们在消费入口加了一张幂等去重表：dedup_key = (orderId, msgId)，命中即丢弃。

上线三周后出了两件事：一是 Redis 里 dedup key 涨到 4.7 亿条、占用 61GB，凌晨被 OOM 驱逐，驱逐窗口内正好有一波 2 万条重复消息漏过、重复落库；二是我们一开始用 SET dedup:{key} 1 EX 600，把 TTL 设成 10 分钟，可生产端 delivery.timeout.ms=120s 的重试窗口是 2 分钟，TTL 比重试窗口短，落在 60s~120s 区间的那次重试全部穿透去重。

这两个问题本质是同一个：幂等去重窗口的大小、清理策略、误判率，是三个独立但互相耦合的工程决策，而大多数团队只当它是「加个 Redis key」。

二、原理：去重窗口的下界由「生产端重试窗口」决定，不是拍脑袋

去重要兜住的，是「同一条消息被投递多次」的时间跨度。这个跨度由生产端决定：

acks=all + idempotent producer（enable.idempotence=true）下，单条消息最多重试到 delivery.timeout.ms（我们设 120s）；
消费端 rebalance 时，未 commit 的那批 max.poll.records（我们 500 条）会被重投；
加上 broker 端副本同步 + 网络抖动，经验上取 2 × delivery.timeout.ms + rebalance 重投量 作为窗口下界。

所以窗口下界 ≈ 240s + 重投批次的生命周期，而不是「设个 60s 图省事」。TTL 一旦小于这个下界，窗口外的重试就会穿透——这就是我 10 分钟 TTL 翻车的根因：120s 的 delivery.timeout 里，落在 60s~120s 区间的那次重试，去重表里对应 key 已经过期被清，等于没去重。

三、具体做法：窗口、存储、误判率三件套

1) TTL 对齐重试窗口，而不是随意取整。 把去重 key 的 TTL 设为 ceil(2 × delivery.timeout.ms / 60) 分钟，保留秒级精度，别四舍五入到 10 分钟：

# 生产端：Kafka 3.5
acks=all
enable.idempotence=true
delivery.timeout.ms=120000
request.timeout.ms=30000
max.in.flight.requests.per.connection=5   # 幂等下允许 >1，靠 PID+序列号保序

# 消费端
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000

2) 用「位图 / 布隆 + 短 TTL」代替裸 Redis string。 3800 万条/天，裸 string 每条约 100+ 字节（含 key 前缀），一天就是 3.8GB 级增量，一周 27GB，直接打爆。改成按天分桶的位图：

# 位图：一天 86400s × 8bit = 691200 槽位 ≈ 85KB
def mark_dedup(msg_id: int, ts: int) -> bool:
    day_bucket = ts // 86400
    bit = msg_id % (86400 * 8)
    key = f"dedup:bit:{day_bucket}"
    return redis.setbit(key, bit, 1) == 0   # 0 表示「之前没置位」→ 非重复

位图一天 85KB，比裸 string 省 4 个数量级。代价是布隆式误判：不同 msgId 可能哈希到同一 bit，key 空间远大于槽位时冲突率不可忽略——所以位图只适合低风险链路，账务类必须退回「Redis string + 精确 TTL」双写。

3) 清理策略：按「天」分桶 + 过期整桶删，而不是逐 key TTL。 逐 key TTL 在 4 亿 key 下，Redis 的 active expire 采样会拖慢整个实例；改成按天分桶 dedup:bit:{day}，到期 DEL 整桶，O(1) 释放内存。

四、踩过的坑：三个反直觉

TTL 比重试窗口短 = 去重失效，且完全静默。 没有任何报错，只是重复落库，对账时发现账不平才查。去重系统失效时不会「告警」，只会「默默多算」。
位图省内存，但把「精确去重」降级成「概率去重」。 位图/布隆本质是 false-positive only，对「多算一次钱」的支付链路不可接受，我后来按业务风险分级：账务类走精确 string，通知类走位图。
rebalance 会让「正在处理中」的那批消息既没去重、又没落库。 8 实例消费组里，一次滚动发布触发 2~3 次 rebalance，max.poll.records=500 的在途消息被重投，去重表里它们的 key 还没置位——所以去重必须「先置位再处理」，且置位要原子，否则并发抢同一分区时会双双通过。

五、结论与可复用清单

幂等去重不是「加个 Redis key」，而是四个独立决策：窗口下界（对齐生产端 2×delivery.timeout）、存储形态（按风险分级选 string / 位图 / 布隆）、清理策略（按天分桶整桶删）、置位时序（先原子置位再处理）。

可复用清单：

去重 TTL ≥ 2 × delivery.timeout.ms，且别四舍五入到整分钟；
账务类走精确去重（Redis string + 精确 TTL），通知类可走位图/布隆换内存；
按「天」分桶 + 整桶 DEL，避免 4 亿 key 的逐 key TTL 拖垮 Redis；
去重要「先原子置位、再处理」，置位与判重合并成 SET key val NX EX ttl 一条命令原子完成；
给去重失效加「重复落库率」监控（对账侧），因为去重失效是静默的。

留一个开放问题给大家：当去重窗口必须开到 10 分钟以上、key 量到亿级时，位图误判率和精确存储的内存成本之间，你们是怎么量化的？有没有把误判率直接当成一个 SLO 来管的实践？

赞 4 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。