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

【背景】

去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径：

订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。

最初用 Kafka 事务（enable.idempotent = true + enable.transactions = true），但发现事务的复杂性与性能损耗过高，最终选择用 Outbox + 业务幂等实现 exactly-once。

【常见分歧】

• 全链路事务：确保 Kafka 生产与消费的原子性，但实现复杂，性能损耗大，不适用于高吞吐场景。
• Outbox + 业务幂等：通过本地事务保证消息生产的一致性，再在消费者端通过幂等机制保证消费的幂等性，实现 exactly-once，但需要业务层对幂等性有深度理解。

【我的倾向与理由】

我倾向于 Outbox + 业务幂等，理由如下：

1. 实现成本低：Kafka 事务需要额外配置和管理，而 Outbox 机制结合本地事务，能更简单地保证消息生产的一致性。

2. 性能更优：Kafka 事务会带来较大的性能开销，尤其是在高吞吐场景下，而 Outbox + 幂等能更灵活地控制消息生产与消费的节奏。

3. 可扩展性更强：Outbox 可以配合其他机制（如消息重试、死信队列）灵活应对异常场景，而全链路事务在复杂链路中容易形成单点故障。

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

• 你们在什么场景下选择全链路事务？
• Outbox + 业务幂等方案是否适用于所有场景？
• 对于高吞吐、低延迟的场景，你们更倾向于哪种方案？

欢迎分享你们的实践与思考！