Kafka Exactly-Once边界之争：Outbox+幂等 vs 全链路事务，你的选型逻辑是什么？

【背景】 Kafka 作为主流消息中间件，其 Exactly-Once 语义实现一直是高阶话题。我们团队在落地过程中发现：

• Outbox+业务幂等方案实现简单，但需业务层强依赖
• 全链路事务方案强一致性高，但实现复杂度呈指数级增长

【常见分歧】

1. 业务侧：认为「只要保证消息不丢失+不重复」即可，反对引入分布式事务
2. 技术侧：坚持「最终一致性」无法满足金融级场景，必须用两阶段提交
3. 成本侧：全链路事务导致吞吐量下降 30%+，需权衡业务价值

【我的倾向】 目前倾向 Outbox+幂等方案，理由如下： ✅ 实现简单：只需在业务层加唯一ID+状态机 ✅ 成本可控：避免分布式事务的复杂度 ✅ 风险可接受：通过业务幂等兜底，配合 Kafka 事务消息

但需注意：当业务层无法保证幂等（如需外部系统协同）时，全链路事务是必要选择

【想听你的观点】 你遇到过哪些场景必须用全链路事务？ 哪些场景下 Outbox+幂等反而导致系统崩溃？ 请用「业务场景 + 技术选型 + 成本收益」三要素阐述你的决策逻辑