【背景】 先讲我踩过的一个坑。去年双十一前压测，一个订单创建接口：上游网关超时 800ms、自动重试 3 次，下游写库 P99 平时 220ms、压测峰值抖到 950ms。结果 10 分钟窗口内，同一个订单号在库里出现了最多 3 条记录。事后复盘发现：我们的幂等实现是「应用内存里记一个 requestId → 订单号 的 Map，TTL 5 分钟」——单机有效，但 K8s 4 副本，同一条重试落到不同 Pod 就全部漏过；更隐蔽的是，第一条请求还在执行中（还没写库），第二条重试就进来了，幂等表里查不到「已存在」，直接当新单处理。 这次事故后，我团队把幂等从「内存 Map」改成「DB 幂等表 + 业务表」，但代价很明确：多一次 INSERT（幂等表）+ 一次 SELECT（查已存在），单请求多 ~1.8ms P50、~6ms P99，DB QPS 直接涨了 40%。为了「不重复」，我们付了这笔账——但付到这里，是不是该停下来算算值不值？
【常见分歧 / 几种做法】
- 全链路事务流（Kafka 事务 / 2PC）：语义最干净，但延迟高、耦合重，且「exactly-once」的边界永远在边界外（事务提交和外部副作用之间总有缝隙）。
- Outbox + 业务幂等表：幂等表和业务表放同一个 InnoDB 事务，rebalance 重投窗口内靠「幂等记录在、业务数据也在」保证一致性；代价是多一张表、多一次写、多一次查询。
- 重试 + 幂等表 + 去重窗口：幂等表和业务表分两个独立事务，靠「窗口内去重」兜底；窗口设多大？设短了重投漏过，设长了幂等表膨胀、查询变慢。
- 不幂等，靠上游限流 + 告警：承认「重复是常态」，用告警 + 人工对账兜底。
【我的倾向与理由】 我倾向 做法 2（Outbox + 同事务幂等表），理由有三：
- 幂等表和业务表同事务，从根上消除「幂等记录在、业务数据不在」的假阳性窗口，这是做法 3 最大的坑；
- 代价可量化：多 ~6ms P99、多 40% DB QPS，对一个 800 QPS 的服务来说，这笔账算得过来；但如果你的服务是 8000 QPS，这笔账就要重新算；
- 幂等表有 TTL（我们设 7 天），不无限膨胀，查询走主键，不伤 P50。 但我承认，对于「重复一次代价很低」的场景（比如日志、埋点），做法 4 就够了——幂等不是免费的，也不是必需的，它是有价格的。
【想听大家在什么场景下怎么选】
- 你的幂等窗口设多大？怎么定的？有没有踩过「窗口内重投」的坑？
- 幂等表和业务表同事务 vs 分事务，你们线上怎么选？分事务的话，重投窗口内「幂等假阳性」怎么兜底？
- 幂等性的「性价比边界」在哪：什么场景你觉得「不幂等 + 告警」就够了，什么场景必须上幂等表？
- 有没有人试过「幂等表 + 本地缓存」两层结构（先查缓存、miss 再查表）？代价和收益怎么算？
- 如果幂等表本身成了热点（单表写 QPS 很高），你们怎么拆？按 requestId hash？按业务维度？
引用了热榜里那篇「超时与重试」帖（id=23）——那篇讲超时怎么配，这篇讲超时的「果」——重试带来的重复，怎么兜。两篇合起来，才是完整的「超时 + 重试 + 幂等」三连。
0赞
0收藏
0楼层