Kafka 三层幂等键（Outbox 业务键 / messageId / 外部 API requestId）不一致：哪层是权威？「本地已写、外部未写」的中间态怎么兜？

背景

订单 → 履约 → 第三方物流这条链路，Kafka 3.6（3 broker），topic order-event 32 分区按 order_id 哈希，at-least-once + 幂等表。三层幂等键各自独立：

• 生产端（订单服务）：Outbox 表 t_outbox，业务键 biz_key = tenant_id|order_id|event_type|event_version（唯一索引），业务事件写 Outbox → Kafka 生产端扫描投递 → 投递成功标记 SENT。messageId 用 UUID.randomUUID()，在 retry 循环里每次重新生成。生产端用 transactional producer（transaction.timeout.ms=60s），"写 Outbox + 投 Kafka"在一个 Kafka 事务里。
• 消费端（履约服务）：幂等表 t_consumed_message，唯一键 uk_message_id。处理流程：解析 → 幂等表查重 → 写本地 t_fulfillment → 调外部物流 API（requestId = biz_key）→ 提交 offset。
• 外部 API（第三方物流）：幂等键 requestId，TTL 24h，超时 ≠ 失败（可能已成功也可能未成功）。

现象（线上踩过的三个坑）

1. Kafka 事务 abort 后 retry，messageId 漂移：事务超时 / broker 抖动导致 abort，catch 后 retry，retry 时 messageId 重新 UUID.randomUUID() → 两条消息 messageId 不同、biz_key 相同 → 消费端 uk_message_id 全部放行 → 本地 t_fulfillment 被写两次 → 外部 API 用 biz_key 只执行 1 次。结果：本地状态多写、外部只执行 1 次，两边对不上，对账脚本天天报警。

2. Outbox 表"删除后重插"（数据修复脚本误操作）：biz_key 相同、messageId 不同 → 同上问题。但这种情况业务上希望重新消费（因为第一次消费可能已经失败），改成按 biz_key 幂等又会挡住合法的重新投递。

3. 消费端「写本地 → 调外部」的中间态：写本地成功 → 调外部 API 超时（不确定是否成功）→ 消费者重试时：

   • 按 messageId 拦截 → 直接放行（messageId 没变）→ 跳过外部调用 → 外部可能没执行，本地却是"已发货"
   • 按 biz_key 拦截 → 跳过外部调用 → 同上
   • 不拦截、重新调外部 → 外部用 biz_key 拦截（已执行过）→ 本地状态被覆盖（可能丢字段）

   核心矛盾：本地状态和外部状态没有事务边界，任何一层失败都会留下"本地已写、外部未写"或"本地未写、外部已写"的中间态，且无法从中间态反推真实状态。

已尝试的排查与结果

1. 消费端幂等表只按 messageId：挡不住 messageId 漂移（retry 生成新 UUID）。
2. 消费端幂等表改成按 biz_key：挡住重复，但挡住合法重发（Outbox 删除后重插是合法的，业务希望重新消费）。
3. 外部 API 用 biz_key：挡住重复执行，但本地状态已经写过了，无法回退。
4. 消费端流程改成「调外部 → 写本地 → 提交 offset」：外部超时不确定是否成功，回退也回不了（不知道外部到底执行了没有）。
5. 用本地事务包「写本地 + 写 outbox 状态」，外部 API 失败时回滚本地：但外部超时 ≠ 失败，回滚可能丢掉真实成功的执行。
6. 生产端 messageId 改成 biz_key + 序号 派生（而不是 UUID）：挡住了 retry 漂移，但 Outbox 删除后重插时 messageId 又相同 → 消费端误拦截合法重发。

期望得到的答案形态

1. 三层幂等键的层级契约：业务键（biz_key）/ 消息键（messageId）/ 请求键（requestId）哪一层是权威？权威层失效时其他层怎么兜？有没有一个"幂等键的权威层级模型"可以直接套？
2. 生产端 messageId 的正确生成方式：Kafka 事务 abort 后 retry 时，messageId 应该用 UUID 还是用 biz_key 派生？还是应该用 Kafka 的 transactional.id + sequence 做幂等键？有没有不依赖 messageId 稳定性的方案？
3. 消费端「写本地 + 调外部」中间态的兜底方案：
   • 消费端也写 outbox（反向 Outbox）→ 异步补偿？具体怎么设计？
   • 本地事务 + Saga（补偿事务）→ 补偿事务怎么设计、补偿键是什么？
   • "写本地 → 调外部 → 写确认记录 → 提交 offset" 四步流程，每步失败怎么回退？
   • 有没有代码级可复现的方案（伪代码即可）？
4. 对账机制：哪一层做对账、对账键是什么（biz_key？messageId？requestId？）、对账窗口多长（24h？7d？）、对账脚本的 SQL / 逻辑长什么样？

背景参考

社区关于 at-least-once + 幂等的讨论不少，但都是"消费端幂等够不够"的层面，没有专门讨论"三层键不一致时谁兜底"的问题：

• 讨论 1598（at-least-once + 幂等在 90% 场景更稳）
• 讨论 1560（at-least-once + 幂等到底够不够，何时必须退回强一致）
• 讨论 1425（幂等解决了重复，但「乱序」才是更隐蔽的坑）

我这个问题和它们的角度不同：不是"要不要幂等"，而是"幂等键有三层、每层都可能失效、权威层级怎么定"。