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

【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。

最初用 Kafka 事务（enable.idempotent = true + enable.transactions = true），但发现事务管理复杂，且 Kafka 事务的可靠性依赖于 Kafka 集群的稳定性。

于是，我们尝试了 Outbox + 业务幂等的方案，将消息的幂等性放到业务层处理，避免 Kafka 事务的复杂性。

【常见分歧】

1. Kafka 事务 vs Outbox + 业务幂等：

   • Kafka 事务：强一致性，但依赖 Kafka 集群稳定性，实现复杂。
   • Outbox + 业务幂等：实现简单，但需要业务层做幂等处理，存在潜在的重复处理风险。

2. 全链路事务 vs 本地事务 + Kafka 事务：

   • 全链路事务：强一致性，但对数据库和 Kafka 都有锁，性能差。
   • 本地事务 + Kafka 事务：性能好，但存在消息丢失风险。

【我的倾向】 我倾向于 Outbox + 业务幂等的方案，因为：

• 实现简单，易于维护。
• 业务层可以灵活处理幂等性，避免 Kafka 事务的复杂性。
• 在 Kafka 集群不稳定时，业务幂等能减少数据丢失的风险。

【想听大家的】 你们在实际生产中是如何选择的？

• 在哪些场景下使用 Kafka 事务？
• 在哪些场景下使用 Outbox + 业务幂等？
• 是否有全链路事务的实际案例？

欢迎分享你的经验和见解！