Kafka 的 exactly-once 边界到底在哪？Outbox + 业务幂等 vs 全链路事务，你们线上怎么选？

【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。

最初用 Kafka 事务（enable.idempotent + enable.transactions），但发现一些问题：

• 事务提交失败时，数据库写入可能已经完成，导致数据不一致。
• 事务超时或重启时，消息可能丢失。

于是尝试用 Outbox 模式 + 业务幂等，发现：

• 需要额外维护幂等 key，增加了复杂度。
• 需要确保业务逻辑的幂等性，对某些场景不够灵活。

现在我们正在考虑是否采用全链路事务（比如 Seata、Saga），但又担心性能开销。

【常见分歧】

1. Kafka 事务 vs Outbox + 业务幂等：
   • Kafka 事务在 Kafka 3.5 后支持，但需要配合事务性生产者和消费者。
   • Outbox 模式在数据库层面保证消息幂等，但需要额外维护。
2. 全链路事务 vs 分布式最终一致性：
   • 全链路事务（如 Seata）能保证强一致性，但性能开销大。
   • 分布式最终一致性（如 Kafka 事务 + 业务幂等）性能好，但需要设计良好的幂等逻辑。

【你的倾向与理由】 我认为，在大多数业务场景中，Outbox + 业务幂等 是更优的选择，原因如下：

• Kafka 事务虽然能保证消息的 exactly-once，但需要配合事务性生产者和消费者，增加了复杂度。
• Outbox 模式可以结合数据库的事务性，避免消息丢失，同时减少对 Kafka 事务的依赖。
• 业务幂等可以在业务逻辑中处理，避免额外的复杂性。

【想听大家在什么场景下怎么选】

• 你们在什么场景下选择 Kafka 事务？遇到了哪些问题？
• 有没有在业务逻辑中实现幂等的经验？
• 在性能与一致性之间，你们的权衡标准是什么？
• 是否尝试过全链路事务？效果如何？