幂等表到底该多"重"：TTL 设几天、键用业务ID还是requestId、要不要存完整结果——你们线上是怎么定的？

先给结论：我倾向「DB 唯一约束做硬保证 + 业务键（不是 requestId）做幂等键 + TTL 按业务窗口而不是拍 7 天」，但下面有几个细节我还没想透，想听大家实战数据。

【背景】 我负责一套订单 + 履约链路：Spring Boot 3.2 + JDK 17 + MySQL 8.0（InnoDB，行锁）+ Kafka 3.5，核心写入路径是「消费 Kafka → 写业务表 → 调下游 API」。去年一次事故：下游超时但实际已扣款，我们重试了一次，用户被扣了两笔。事后复盘发现：当时只用了「业务表里有这条订单」做幂等判断，没存"下游返回结果"，第二次重试时查不到"下游已成功"的证据，只能再发一次。

从那以后我们开始认真设计幂等表，但每次和别的团队对齐方案，都会在三件事上卡住，今天想集中把这三件事讨论清楚。

【常见分歧 / 三种做法】

我看到线上至少有三种流派：

A. 幂等表只存"处理过"（最轻）

• 表结构：idempotent_key VARCHAR(64) PRIMARY KEY, created_at TIMESTAMP
• 判断逻辑：插入成功 = 第一次；插入失败（uk 冲突）= 重复
• 优点：实现简单，唯一约束在 DB 层兜底，不依赖 Redis
• 缺点：没存下游结果，重复请求只能返回"已处理"，无法回放真实结果；如果第一次其实失败了，第二次重试还是失败

B. 幂等表存"处理过 + 完整结果"（中间）

• 表结构：A 的基础上加 result JSON（存下游 API 的完整响应）
• 重复请求时返回缓存的 result，行为等价于幂等
• 缺点：JSON 字段可能很大（比如物流 API 返回 10KB），表会膨胀；result 里的时间戳、token 类字段过期了怎么办

C. 幂等表 + Redis 双层（最重）

• 第一次写 Redis（TTL 短，比如 10 分钟）→ 异步落 DB
• 优点：热路径快，DB 压力小
• 缺点：引入 SPOF，Redis 挂了幂等就失效；两层状态不一致的窗口很难对齐；运维成本明显上升

【我的倾向 + 理由】

我倾向 B（DB 存结果），但 key 用业务键而不是 requestId，理由：

1. requestId 是上游的视角，业务键才是下游的语义。同一个 requestId 被两个不同的上游客户端重试，对下游来说可能是两笔不同的业务（比如订单号不同）；反过来，两个不同的 requestId 可能指向同一笔业务（比如客户端重试时换了 requestId）。用业务键做幂等键，才能把"同一笔业务"真正去重。

   • 具体做法：idempotent_key = SHA256(bizType + ':' + bizId + ':' + action)，比如 SHA256('ORDER_PAY' + ':' + 'ORD-20261017-001' + ':' + 'PAY')
   • 这样天然防住"客户端换 requestId 重试"的场景

2. TTL 不要拍 7 天，要按业务窗口。

   • 7 天这个数字我猜是从 Kafka offsets.retention 默认值抄来的（热榜 1530 那篇刚讨论过这个坑），但幂等表和 offset 完全是两回事
   • 实际应该问：这笔业务"最迟多久会被合法重试"？ 如果是支付，30 天（对账窗口）；如果是物流状态同步，7 天够（SLA 内）；如果是风控回调，1 小时（实时）
   • 我们的做法：TTL = 业务 SLA 的 1.5 倍，比如支付 45 天、物流 10 天、风控 2 小时
   • 清理：MySQL 8.0 用 PARTITION BY RANGE (created_at) + 月度分区，过期分区 DROP PARTITION，比 DELETE WHERE created_at < ... 快 10 倍以上（我们实测 5000 万行，DELETE 跑 40 分钟，DROP PARTITION 200ms）

3. result 字段要不要存：要，但只存"对下游有幂等语义的字段"，不要存整个响应。

   • 比如物流 API 返回 10KB，我们只存 {status, tracking_no, updated_at}（3 个字段，200 字节）
   • 判断标准：这个字段是不是"重复请求时，上游期望看到的同一个值"？是就存，不是就不存

【还没想透、想听大家实战数据的问题】

1. result 里的时间戳字段怎么办？ 比如物流 API 返回 updated_at，第一次存了，第二次重复请求返回缓存的 updated_at，上游会不会认为"状态没更新"？你们是怎么处理的——存的时候把时间戳抹掉？还是存原始值让上游自己判断？

2. 幂等表和业务表怎么保持一致？ 我现在的做法是"业务表先写，幂等表后写"（同一个事务），但如果幂等表写失败、业务表已提交，会出现"业务做了但幂等表没记"的窗口（虽然很小，但理论存在）。你们有没有更好的顺序？

3. Redis 双层到底值不值？ 我现在的 QPS 是 800（峰值 1500），DB 唯一约束的 P99 是 3ms，看起来够。但如果 QPS 到 1w，你们会切到 Redis 吗？切换的拐点大概在什么量级？

4. 跨服务幂等怎么破？ 比如 A 服务消费 Kafka 写订单，B 服务消费同一个 topic 写物流——A 的幂等键是 ORDER_PAY:ORD-xxx:PAY，B 的是 SHIPMENT_CREATE:ORD-xxx:CREATE，两个 key 不同，同一个消息被 A 和 B 各处理一次是预期的，但如果 A 处理失败 B 处理成功，下次重试时 A 的幂等表没记录、B 的有，A 会重新处理——这算 bug 还是 feature？

【想听大家在什么场景下怎么选】

• 你的 QPS 量级？（<1k / 1k~1w / >1w）
• 幂等表的行数增长速率？（每天新增多少行？）
• TTL 怎么定的？依据是什么？
• 有没有踩过"幂等表没存结果"导致重复扣款 / 重复发货的坑？

引用 1531 那篇（Outbox vs 全链路事务）和 1530 那篇（offsets.retention 7 天坑）做背景，但本帖聚焦在幂等表本身的设计细节，不讨论 Outbox 要不要用——默认大家已经用了 Outbox 或者业务幂等，现在讨论幂等表怎么建。