Kafka 事务超时 abort 后外部 API 副作用无法回滚：transaction.timeout.ms 设多大才够、abort 后重试时外部 API 幂等怎么保？

背景

我负责一条支付回调链路，Kafka 3.5（KRaft，3 broker），topic payment-callback 16 分区，消费组 4 实例。消费端用 Kafka 事务（isolation.level=read_committed，transactional.id 固定），单条消息处理四步：

1. 调外部支付渠道 API 查交易状态（P50=200ms，P99=8s）
2. 调外部风控引擎 API 做风险评估（P50=500ms，P99=45s，偶发 80s）
3. 写 MySQL 8.0 更新订单状态
4. 提交 offset（在事务内，Spring Kafka 事务监听器）

transaction.timeout.ms=60s（默认值）。

现象

风控 API P99=45s，加上其他步骤，偶尔超过 60s → 事务超时 abort → broker 标记 abort → consumer 重新消费 → 外部 API 被再次调用。

• 支付渠道 API 查交易状态是只读的，重复调用无副作用，无所谓。
• 但风控引擎 API 有写入副作用：每次调用都会生成一条评估记录（写入风控引擎的评估流水表），重复调用导致评估记录翻倍，下游风控报表数据失真。
• 更严重的一次：风控 API 在 abort 后、重试前宕机了 30s，恢复后重试时风控 API 返回了与第一次不同的评估结果（因为风控模型的实时特征在 30s 内变了），导致同一笔订单被风控引擎评估了两次且结果不一致，下游策略引擎按第二次结果执行，风控判定被"翻转"——第一笔是"放行"，第二笔是"拦截"，最终按"拦截"执行，但第一笔的"放行"副作用（已发出的通知）无法撤回。

核心裂缝：Kafka 事务只能原子回滚「写 topic + 提交 offset」，外部 API 的副作用不在事务边界内。abort 后重试，外部 API 被再次调用，且第二次调用的结果可能与第一次不同（因为外部系统的状态在两次调用之间变了）。

已尝试的排查与结果

1. 把 transaction.timeout.ms 从 60s 调到 300s（5min）：事务超时频率降了约 80%，但风控 API 偶发 80s 时仍然超时。调到 900s（15min，Kafka 上限）理论上能覆盖，但事务持锁时间过长，broker 的 __transaction_state 表里堆积了大量 open 事务，initTransactions() 的 P99 从 50ms 涨到 2s，其他 producer 实例被阻塞。

2. 把风控 API 调用从事务内拆出来（先调 API，再开事务写 Kafka）：裂缝更大了——「调 API 成功 + 写 Kafka 失败」时，API 调了但消息没发出去，重试时 API 又被调一次，而且没有事务保护，offset 提交和 API 调用的原子性完全丢失。

3. 给风控 API 加幂等键（基于 order_id + callback_id）：风控 API 的幂等是查询级的（同一 key 返回同一结果），不是写入级的（同一 key 只写一次评估记录）。所以重复调用仍然会产生多条评估记录，只是结果相同。写入级幂等需要风控引擎侧改造，我们推动不动。

期望得到的答案形态

几个具体问题，欢迎带着你的真实场景来聊：

1. transaction.timeout.ms 你们怎么设？ 有没有团队设到 15min 上限的？设到 15min 后 __transaction_state 的堆积和 initTransactions() 的阻塞你们遇到过吗？

2. 如果外部 API 的 P99 超过了 transaction.timeout.ms 的上限（15min），你们怎么拆？ 是把 API 调用拆到事务外 + Outbox 兜底，还是干脆放弃 Kafka 事务改用 at-least-once + 业务幂等？

3. abort 后重试时，外部 API 的写入级幂等怎么保？ 有没有团队在消费端维护一张「外部 API 调用记录表」（order_id + api_type + 调用时间 + 结果），重试时先查表、命中则跳过 API 调用直接用缓存结果？这张表的生命周期谁管？

4. 有没有团队把「外部 API 调用」从 Kafka 事务里彻底拆出来，用 Outbox 模式兜底（API 调用结果写 Outbox 表，再由独立 sender 发消息给下游）？这种拆法的代价是什么？

5. 一个更激进的问题：你们有没有团队完全不用 Kafka 事务，而是用 at-least-once + 外部 API 幂等 + 业务状态机来绕过这个问题？这种做法的边界在哪里——哪些场景下"外部 API 副作用不可回滚"是致命的，哪些场景下"容忍重复调用"是可接受的？

我不打算给标准答案——这个问题的核心变量是外部 API 的 P99 耗时和外部 API 的副作用是否可回滚，这两个变量决定你是在事务内等、还是在事务外拆、还是干脆不追 EOS。想听听大家在不同 API 耗时分布和不同副作用可回滚性下的实际选择。