【背景】 我最近接手一条支付回调链路：Kafka 3.5（3 broker，KRaft）→ 消费端 Spring Boot 3.2 → MySQL 8.0 落幂等表。消息是 at-least-once 投递，消费端用「幂等表 SELECT + INSERT 唯一索引」做去重。
上线后遇到一个很尴尬的问题：幂等表 t_idempotent 设计时 TTL 设了 7 天（业务方说"7 天内重复回调都算有效"），但 Kafka 的 rebalance + consumer offset commit 延迟组合起来，实际重复窗口能拉到 30 分钟以上（rebalance 30s + max.poll.interval 5min × 2 次重试 + 下游超时重试 3 次）。
更麻烦的是，有一类"延迟补偿消息"（T+1 对账触发的补单）会跨越 7 天 TTL 窗口——幂等表已经删了记录，补单消息重新投递时直接绕过了幂等去重，落库出现了重复扣款记录。
【常见分歧 / 几种做法】
- TTL = 业务窗口：幂等表 TTL 对齐业务有效期（7 天 / 30 天），超过窗口的消息视为"新请求"重新处理。简单直观，但跨窗口重复就翻车。
- TTL = 消息重复窗口 × 安全系数：只覆盖 at-least-once 的重复投递窗口（通常 < 1h），超过窗口的消息靠业务层兜底。省存储，但要求业务层自己处理"幂等表里没有"的情况。
- 两层幂等：短窗口（1h）用幂等表，长窗口（7 天）用业务唯一键（如 order_id + action_type）做数据库层兜底。最稳但实现复杂，维护成本高。
- 不删，只归档：幂等表不删记录，按月 / 按季度归档到冷存储。存储成本换确定性，但表会越来越大，查询需要走归档逻辑。
【我的倾向与理由】 我倾向方案 3（两层幂等）+ 方案 1 的 TTL 兜底，理由：
- 消息中间件的重复窗口是「不可控」的（rebalance 时机、broker GC、网络抖动都会拉长），用 TTL 硬卡一个上限本质上是赌"窗口不会超过 TTL"，这在 at-least-once 语义下是个危险的赌注。
- 但两层幂等的维护成本也是真实的：多一张表、多一个查询路径、多一套归档策略。如果业务场景里"跨窗口重复"概率极低（< 0.01%），方案 2 其实够用。
- 关键判断标准：你的业务能不能承受"幂等表记录被 TTL 清理后，同一条消息被重复处理一次"的后果？如果能（比如只是发一条重复通知），方案 2 够了；如果不能（比如重复扣款），必须方案 3。
【补充：两层幂等的 MySQL 落地细节（踩过的坑）】 方案 3 在 MySQL 上有一个隐藏坑，这里补一下，给后来抄作业的人：
1. 长窗口的「业务唯一键」必须建在业务主表上，而不是幂等表上
我第一版把 UNIQUE(order_id, action_type) 建在 t_idempotent 上，结果 TTL 清理后这个约束也跟着没了——和"删了记录"是同一件事。正确做法是约束建在 t_payment（业务主表）上，幂等表只做"短窗口快路径"，业务主表的唯一索引才是"长窗口兜底"。这样 TTL 清理幂等表记录后，重复消息进来 → 幂等表查不到 → 走业务主表 INSERT → 撞唯一索引 → 报 DuplicateKeyException → 业务层判定为"重复"。
2. DuplicateKeyException 的语义要区分
不是所有 DuplicateKeyException 都等于"重复消息"。比如 order_id 本身被业务方复用（改单、重开单），也会撞唯一索引。我们后来在幂等表里加了一个 source_msg_id 字段（Kafka 的 message key 或业务侧的全局唯一 ID），短窗口走 UNIQUE(source_msg_id)，长窗口走 UNIQUE(order_id, action_type)，两条约束分开判。
3. 两层查询的成本 短窗口命中（99%+ 的重复消息）：1 次幂等表 SELECT（主键索引，< 0.1ms）→ 直接 return。 短窗口未命中 + 长窗口命中（< 0.1%）：1 次幂等表 SELECT miss + 1 次业务主表 INSERT 撞唯一索引 → 报异常 → 1 次业务主表 SELECT 确认 → return。 短窗口未命中 + 长窗口未命中（正常新消息）：1 次幂等表 SELECT miss + 1 次业务主表 INSERT + 1 次幂等表 INSERT（记录短窗口）= 3 次 DB 操作。 实测 P99 增加约 0.3ms（多了一次幂等表 SELECT miss），可以接受。
4. 归档 vs TTL 清理的取舍 我们最终选的是"TTL 清理幂等表 + 业务主表不删"，而不是"归档"。原因：归档后查询路径变成"先查热表 → miss 再查归档表"，跨库或跨引擎时 P99 会劣化；而业务主表不删的话，唯一索引永远在，查询路径不变。存储成本：t_payment 的 order_id 唯一索引，按 1 亿行估算约 2~3GB，可接受。
【想听大家怎么选】
- 你们线上幂等表的 TTL 一般怎么定？是跟业务窗口对齐，还是跟消息重复窗口对齐？
- 有没有人踩过"幂等表 TTL 太短导致跨窗口重复"的坑？当时怎么补救的？
- 两层幂等（短窗口幂等表 + 长窗口业务唯一键）的实际维护成本你们怎么评估的？值不值？
- 如果让你用一句话总结"幂等窗口该多长"，你会说什么？