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

【背景】 在 Kafka 的 exactly-once 实践中，我们常常面临一个关键问题：究竟应该在消息生产端使用 Outbox + 业务幂等，还是在全链路使用事务来保证一致性？

【常见分歧】

• Outbox + 业务幂等：
  • 优点：实现简单，对 Kafka 本身的事务支持要求低。
  • 缺点：业务幂等逻辑需要额外开发，且可能引发性能瓶颈。
• 全链路事务：
  • 优点：保证端到端一致性，无需额外幂等逻辑。
  • 缺点：实现复杂，对 Kafka 事务支持要求高，且可能影响吞吐量。

【我的倾向与理由】 在实际项目中，我们倾向于使用 Outbox + 业务幂等 的方案。原因如下：

• Kafka 的事务支持虽然强大，但在高并发场景下，全链路事务可能导致性能下降。
• 业务幂等逻辑可以通过数据库的唯一约束或幂等键来实现，这在大多数业务场景中是可行的。
• 这种方案更灵活，可以根据业务需求调整幂等逻辑。

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

• 你们在哪些场景下选择了全链路事务？
• 有哪些实际案例或经验可以分享？
• 对于高吞吐量的场景，你们是如何平衡一致性和性能的？