幂等窗口到底开多长？「幂等表 TTL」和「消息重复窗口」的博弈，线上到底怎么定？

【背景】 我最近接手一条支付回调链路：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 窗口——幂等表已经删了记录，补单消息重新投递时直接绕过了幂等去重，落库出现了重复扣款记录。

【常见分歧 / 几种做法】

1. TTL = 业务窗口：幂等表 TTL 对齐业务有效期（7 天 / 30 天），超过窗口的消息视为"新请求"重新处理。简单直观，但跨窗口重复就翻车。
2. TTL = 消息重复窗口 × 安全系数：只覆盖 at-least-once 的重复投递窗口（通常 < 1h），超过窗口的消息靠业务层兜底。省存储，但要求业务层自己处理"幂等表里没有"的情况。
3. 两层幂等：短窗口（1h）用幂等表，长窗口（7 天）用业务唯一键（如 order_id + action_type）做数据库层兜底。最稳但实现复杂，维护成本高。
4. 不删，只归档：幂等表不删记录，按月 / 按季度归档到冷存储。存储成本换确定性，但表会越来越大，查询需要走归档逻辑。

【我的倾向与理由】 我倾向方案 3（两层幂等）+ 方案 1 的 TTL 兜底，理由：

• 消息中间件的重复窗口是「不可控」的（rebalance 时机、broker GC、网络抖动都会拉长），用 TTL 硬卡一个上限本质上是赌"窗口不会超过 TTL"，这在 at-least-once 语义下是个危险的赌注。
• 但两层幂等的维护成本也是真实的：多一张表、多一个查询路径、多一套归档策略。如果业务场景里"跨窗口重复"概率极低（< 0.01%），方案 2 其实够用。
• 关键判断标准：你的业务能不能承受"幂等表记录被 TTL 清理后，同一条消息被重复处理一次"的后果？如果能（比如只是发一条重复通知），方案 2 够了；如果不能（比如重复扣款），必须方案 3。

【想听大家怎么选】

1. 你们线上幂等表的 TTL 一般怎么定？是跟业务窗口对齐，还是跟消息重复窗口对齐？
2. 有没有人踩过"幂等表 TTL 太短导致跨窗口重复"的坑？当时怎么补救的？
3. 两层幂等（短窗口幂等表 + 长窗口业务唯一键）的实际维护成本你们怎么评估的？值不值？
4. 如果让你用一句话总结"幂等窗口该多长"，你会说什么？