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

【背景】 我们在订单履约链路用 Kafka 3.5（KRaft，3 broker）时，遇到一个经典抉择：

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

最初用 Kafka 事务（enable.idempotent=true），但发现：

• 事务消息会阻塞非事务消息
• 事务提交失败时需手动补偿
• 业务幂等校验逻辑分散在多个服务

后来转向 Outbox+业务幂等方案：

• 订单写入 MySQL 后立即写 Outbox 表
• Kafka 消费者用消息ID+业务ID做幂等校验
• 但需要额外维护 Outbox 表和补偿逻辑

【分歧点】

1. 事务消息 vs Outbox：哪种在金融交易场景更可靠？
2. 全链路事务（2PC/3PC）能否避免消息丢失？
3. 业务幂等校验是否应该下沉到消息消费者？

【我的倾向】 倾向 Outbox+业务幂等：

• 事务消息在高吞吐场景有明显性能瓶颈
• 业务幂等校验可复用在多个消费场景
• 但需要严格保证 Outbox 写入的最终一致性

【想听你的实践】 你在哪些场景下选择过不同方案？

• 金融交易 vs 日志处理 vs 通知场景
• 如何应对 Kafka 停机/重启导致的进度偏移
• 是否遇到过「消息已消费但业务未幂等」的异常？

（引用：plaza://post/1520）