消费端幂等表与非幂等副作用非原子：先写幂等后调 API 会漏操作、先调 API 后写幂等会重复，不引分布式事务线上怎么破？

背景

我们订单履约链路：Kafka 3.5（KRaft，3 broker），topic order-fulfill 16 分区，生产端 outbox 表 + 定时补偿，消费端按社区主流做法走 at-least-once + 幂等表去重（这个选型社区已经讨论得比较透了，我默认它成立，下面问的是它往下再挖一层的卡点）。

消费端处理一条消息要做两件事：

1. 写业务库（订单状态流转）；
2. 调一个非幂等的外部 API（第三方物流下单，调一次就生成一个运单号，重复调 = 重复下单，无法靠业务键天然去重）。

现象 / 卡点

问题出在：幂等表的写入，和这两步副作用，不在同一个事务里，怎么排顺序都有坑。

• 顺序 A（先写幂等表 → 再调外部 API）：调 API 超时（我们外部 API P99 超时 8s），但幂等表已经记了 processed。Kafka 重试这条消息 → 幂等表命中 → 直接 ack 跳过。结果：物流其实没下单成功，系统却认为已处理 = 漏操作。 我们上个月就踩过一次，月底对账才发现 17 单物流缺失。
• 顺序 B（先调外部 API → 再写幂等表）：API 成功返回运单号，但写幂等表那一下碰上 DB 抖动失败。Kafka 重试 → 又调一次 API → 重复下单。

本质是：「幂等表写入」和「非幂等副作用」这两步，既不是原子的，也缺少一个权威的『到底处理成功没有』的状态位——at-least-once 把「不丢」交给了 broker，但「不重」和「副作用到底做没做成」这两件事，幂等表一个 0/1 字段根本扛不住。

已尝试的排查与结果

1. 本地事务绑定：把「幂等表写入 + 业务库写入」放进一个本地事务，至少这两步原子了。但外部 API 依旧游离在事务外，顺序 A/B 的坑没解决。
2. 幂等表状态机：给幂等表加状态 PENDING → SUCCESS / FAILED，意图是「重试时根据状态判断要不要再调 API」。卡在一个细节：PENDING 怎么区分『正在处理中』和『处理中断（崩溃/超时）』？ 后者重试时要继续调 API，前者重试时不能调（避免重复）。光看状态区分不出来，只能加 started_at + 超时判断，又引入「超时阈值到底定多少、依据什么定」的新问题。
3. 考虑过 Outbox / 2PC / TCC：能把外部 API 也纳入事务边界，但引入太重，而且外部 API 是第三方服务、没法配合做 2PC，团队评估后 ROI 不划算，放弃了。

期望得到的答案形态

想听线上真跑过、带数据的方案，而不是「理论上应该怎么做」：

1. 你们消费端「幂等表 + 非幂等外部副作用」到底怎么排顺序？状态机具体怎么设计的？PENDING 的中断恢复怎么判断（超时阈值定多少、依据什么定、怎么避免误判正在处理的请求为中断）？
2. 有没有不引分布式事务、但能让「幂等表写入」与「副作用」足够原子 / 可恢复的轻量方案？（比如本地消息表 + 异步重试队列、或副作用本身做成可查询的「先查后做」？）
3. 你们线上「漏操作」和「重复操作」的失败率大概是多少量级？靠什么监控发现、补偿流程长什么样？

我自己目前倾向于「状态机 + started_at 超时 + 副作用做成先查后做」的组合，但不确定超时阈值在外部 API P99=8s 的场景下怎么定才既不漏又不重，想看看大家是怎么把这个边界画清楚的。欢迎拍砖。