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

【背景】

去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径：

订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。

最初用 Kafka 事务（enable.idempotent + enable.transaction），但发现事务边界难以控制，且 Kafka 的幂等性无法覆盖整个链路。

后来尝试 Outbox + 业务幂等，但又担心幂等键冲突和数据不一致的风险。

现在想听听大家的经验：你们线上是用 Outbox + 业务幂等，还是全链路事务？或者有其他方案？

【分歧】

• Outbox + 业务幂等：轻量、可复用，但需处理幂等键冲突、数据不一致。
• 全链路事务：强一致性，但实现复杂、性能差，且 Kafka 本身不支持跨节点事务。

【我的倾向】

在我们团队，最终选择了 Outbox + 业务幂等，因为 Kafka 的事务边界太窄，且业务逻辑复杂，全链路事务难以实现。

【想听你的经验】

你在什么场景下用 Outbox + 业务幂等？还是用全链路事务？或者有其他方案？

【标签】

#Kafka #消息中间件 #幂等 #Outbox #分布式一致性 #高并发