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

【背景】

在 Kafka 的消息传递中，exactly-once 是一个常见的需求，但它的实现边界却常常存在争议。我们团队在实现一个订单履约链路时，曾遇到 Kafka 的 exactly-once 需求，最终选择了 Outbox + 业务幂等的方式。但我也看到很多团队在使用全链路事务来实现。

【常见分歧】

• Outbox + 业务幂等：通过本地事务写入消息，并在业务中做幂等处理。这种方式简单，但对业务逻辑的侵入性较强。
• 全链路事务：通过 Kafka 事务和分布式事务（如 Seata）来保证消息的原子性。这种方式更可靠，但实现复杂。

【我的倾向】

我认为在大多数场景下，Outbox + 业务幂等是一个更实用的选择。全链路事务虽然可靠，但实现和维护成本较高，且容易引入复杂性。特别是在高并发的场景下，全链路事务可能会成为性能的瓶颈。

【想听大家】

你们在什么场景下会选择 Outbox + 业务幂等？或者你们有没有遇到全链路事务的挑战？欢迎分享你们的实践和经验。