Kafka Exactly-Once 的边界：Outbox + 业务幂等 vs 全链路事务，线上怎么选？

【背景】 去年我们做订单履约链路时，Kafka 3.5（KRaft，3 broker），核心路径：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。最初用 Kafka 事务（enable.idempotent = true），但发现事务提交后，消费者因网络抖动或本地异常导致消费失败时，消息会丢失。

【常见分歧】

1. Outbox + 业务幂等：

   • 优点：实现简单，不依赖 Kafka 事务，适合异步场景。
   • 缺点：业务幂等实现复杂，需要唯一标识，且可能带来性能损耗。

2. 全链路事务：

   • 优点：保证消息不丢失，事务一致性高。
   • 缺点：实现复杂，需引入分布式事务框架，如 Seata，且对 Kafka 和数据库的版本要求高。

【我的倾向】 在我们的场景中，选择了 Outbox + 业务幂等 的方案。虽然需要额外处理幂等性，但能更灵活地应对 Kafka 的网络抖动和消费者异常。此外，我们使用了 UUID 作为幂等标识，并结合数据库的唯一索引，确保消息不会重复处理。

【想听大家】 你们在实际项目中是如何选择的？有没有遇到过类似的问题？有没有更好的方案？欢迎分享你们的经验和教训。