幂等到底该在"提交事务前"还是"提交事务后"做判断？

背景

社区里聊幂等的帖子不少，但大多在讨论「要不要做幂等」「用唯一索引还是 Redis SETNX」这类表层问题。真正让我在评审会上吵过两次的，是一个更底层的顺序问题：

幂等判断的时机——是先 INSERT INTO idempotency_key (key, status='processing')，再开业务事务跑主流程，最后把 status 改成 done？还是先跑完业务事务，commit 成功后再回写一条"已处理"记录？

这两种写法我都在生产里见过，也都在凌晨 3 点被它们坑过。

几种典型做法（按出现频率排）

1. 先占位（processing → done 两段式）：进函数先 insert 一条 processing，业务事务跑完后 update 成 done。优点是对并发重复请求天然互斥；缺点是如果进程在中间挂掉，留下一堆 processing 脏状态，需要 TTL 或人工清理。
2. 提交后回写：业务事务 commit 成功后才写幂等记录。优点是状态干净（要么没有、要么是 done）；缺点是存在一个极短的窗口——两次重复请求在这个窗口内都能拿到"没处理过"，导致重复执行。
3. 靠数据库唯一键硬扛：幂等键直接做成业务表的业务唯一索引，重复请求直接撞 Duplicate Key。优点是零额外表；缺点是所有幂等逻辑都绑死在单库上，跨服务聚合的幂等做不了。
4. Redis SETNX + 业务表双保险：先 Redis 挡并发，业务表唯一键挡持久化。我见过最完整的方案，但运维成本也最高。

我的倾向

我倾向做法 1（两段式占位），但有两个数字上的硬约束：

• processing 状态的 TTL 必须 大于 业务事务 P99.9 的耗时 × 3，我们订单链路 P99.9 是 800ms，所以 TTL 设到 5s；
• 占位表和业务表必须 同库不同表，不要跨库，否则你失去的就是幂等本身。

理由是：分布式里"判断幂等"和"执行业务"永远不是原子操作，任何方案都必须接受一个窗口。与其把窗口藏在 commit 之后（做法 2 的隐蔽风险），不如把窗口显式化成一个可清理的中间态（做法 1）。

想听大家聊的

1. 你们的幂等表是 跟着业务服务走，还是抽成一个独立的 idempotency service？跨服务调用多一次 RPC，值不值？
2. 消费 MQ 消息时的幂等，和 HTTP 接口的幂等，你们用的是 同一套表 还是 两套？
3. 有没有人踩过「幂等表把主库打挂」的事故？我见过一次：一个上游 3 秒内重发了 4 万条重复请求，幂等表的 insert 把主库 CPU 打到 90%。你们怎么防的？