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

【背景】

在高并发系统中，Kafka 的 exactly-once 保证是一个常见的挑战。我们近期在处理一个订单履约链路时，遇到了 Kafka 事务与业务幂等之间的取舍问题。这个系统包括订单创建、写 MySQL、发 Kafka 消息以及消费者调外部物流 API。我们最初尝试使用 Kafka 事务（enable.idempotent 和 enable.transactions），但在实际运行中，出现了数据不一致和重复处理的问题。

【常见分歧】

1. Outbox + 业务幂等：在订单写入 MySQL 后，使用 Outbox 模式记录 Kafka 消息，并通过业务幂等处理重复消息。这种方法的好处是实现简单，但需要在业务层处理幂等逻辑。

2. 全链路事务：使用 Kafka 事务来保证消息的原子性，但这种方法在复杂场景中可能不够灵活，且对 Kafka 的版本和配置要求较高。

【我的倾向与理由】

我倾向于使用 Outbox + 业务幂等的组合。这种方法在大多数场景中表现良好，尤其是在 Kafka 事务支持有限的情况下。业务层的幂等处理可以更灵活地应对各种异常情况。

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

• 你们在哪些场景下选择了 Outbox + 业务幂等？
• 有没有使用全链路事务的经验？遇到过哪些挑战？
• 对 Kafka 的 exactly-once 实现有什么建议？