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

【背景】

我们去年在做订单履约链路，使用 Kafka 3.5（KRaft，3 broker），核心路径是：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。最初我们尝试使用 Kafka 事务（enable.idempotent = true, enable.producer.idempotence = true），但遇到了一些问题。比如，当 Kafka 生产者在发送消息时发生网络波动，导致消息丢失或重复，我们不得不重新考虑 exactly-once 的实现方案。

【常见分歧】

1. Outbox + 业务幂等：

   • 通过数据库事务确保消息的原子性，同时在业务层实现幂等处理。
   • 优点：实现简单，避免了 Kafka 事务的复杂性。
   • 缺点：需要额外的数据库操作，可能影响性能。

2. 全链路事务：

   • Kafka 事务与数据库事务结合，确保消息和数据库操作的原子性。
   • 优点：保证数据一致性，无需额外的幂等处理。
   • 缺点：实现复杂，对 Kafka 和数据库的版本要求较高。

【我的倾向】

我倾向于使用 Outbox + 业务幂等 的方案。因为 Kafka 事务在某些场景下可能不够稳定，特别是在网络波动或 Kafka broker 宕机的情况下，容易导致消息丢失或重复。而通过数据库事务确保消息的原子性，并在业务层实现幂等处理，可以更好地应对这些场景。

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

• 你们在实际项目中是如何选择 exactly-once 的实现方案的？
• 在哪些场景下，你们选择了 Outbox + 业务幂等，而在哪些场景下选择了全链路事务？
• 有没有遇到过 Kafka 事务导致的问题，是如何解决的？