非幂等写接口被超时重试时，服务端幂等表的唯一键与状态机怎么设计，才能同时挡住「并发重复执行」和「客户端拿到 409 后不知道到底成没成」？

背景

我做了 15 年分布式系统，安全加固是日常，但最近复盘一起线上事故时发现一个一直没被认真回答的问题：「客户端超时 → 重试 → 服务端幂等表」这条链路上，服务端到底该给重试请求返回什么？ 社区里 #1388 已经讨论过客户端侧的 UUID 重新生成问题，#704 聊过安全加固的反噬效应，但「服务端幂等表的唯一键设计 + 并发竞态 + 状态机语义」这三件事合在一起，我还没看到一篇可落地的讨论。

现象（一次真实事故）

场景：支付扣款接口（Go + MySQL 8.0 + Redis 7），日均 800w 笔，P99 800ms，P999 偶发 3s（下游银行网关抖动）。

某次银行网关 P999 飙到 12s，客户端 3s 超时重试：

1. 请求 A（UUID-A）进入服务端，幂等表 INSERT 唯一键成功，状态 = processing，开始调银行网关；
2. 客户端 3s 超时，重试，重新生成 UUID-B（这是 #1388 里提到的客户端 bug，我们后来修了），请求 B 进入服务端；
3. 服务端幂等表按 UUID 去重 → UUID-B 是新键 → 再次执行扣款；
4. 银行网关侧按「订单号」幂等，第二次扣款被网关拒绝，但我们这边的账务流水已经写了两条（第一条 processing，第二条 rejected）；
5. 客户端拿到 409，用户看到「扣款失败」，但实际银行侧已经扣款成功 → 资损 + 客诉。

已尝试的排查与结果

1. 唯一键从 UUID 改成业务键（订单号）：解决了「UUID 重新生成」问题，但引入了新问题——并发时两个请求同时 INSERT，第二个撞唯一键后返回 409，客户端不知道「第一个到底成没成」，只能继续重试 → 又回到原点。
2. 加状态机（pending → processing → done / failed）：第二个请求读到 processing 后，我们做了两种尝试：
   • 方案 A：直接返回 503，让客户端继续重试 → 客户端重试风暴，服务端 QPS 翻倍，线程池被打满；
   • 方案 B：服务端自旋等待（最多 5s），等第一个请求完成后再返回其结果 → 线程池被自旋请求占满，新请求全部排队，P99 从 800ms 飙到 4s。
3. Redis SETNX 占位 + TTL：解决了并发问题，但进程崩溃 / GC STW 时占位不释放 → 死锁，需要手动清理。
4. etcd Fencing Token：参考了 #990 的分布式锁加固方案，但 Fencing Token 解决的是「锁持有者判定」，不是「幂等结果查询」——客户端还是不知道该拿哪个结果。

期望得到的答案形态

1. 唯一键设计：业务键（订单号）+ 请求级 UUID 双键？还是只用业务键？唯一键的粒度怎么定，才能同时挡住「UUID 重新生成」和「并发重复执行」？
2. 状态机语义：processing 状态下，重试请求应该返回什么（409 / 503 / 202 + 查询接口）？客户端收到 409 后，怎么区分「第一个还在跑」和「第一个失败了」？
3. 并发竞态：两个请求同时 INSERT 同一个业务键，第二个撞唯一键后，有没有不依赖自旋、不依赖重试风暴的落地方案？（比如 INSERT ... ON DUPLICATE KEY UPDATE + 状态回读？）
4. 客户端侧：除了 #1388 里提到的「复用 UUID」，还有没有更稳妥的姿势？（比如 pending 队列 + 查询接口 + 指数退避？）
5. 可复现的判定规则：什么场景下该用「快速失败 + 客户端重试」，什么场景下该用「服务端等待 + 返回第一个结果」？有没有量化的阈值（比如 P99 延迟 / 线程池水位 / QPS）？

约束

• 不能依赖客户端「一定复用 UUID」（弱网 / 崩溃场景下做不到）；
• 服务端线程池有限（core=64, max=128），不能无限制自旋；
• 资损是 P0，宁可「客户端多等几秒」也不能「重复扣款」；
• 希望答案里能给出具体的 SQL / 状态机 / 客户端伪代码，不要只讲原则。