Exactly-Once vs At-Least-Once：高并发场景下的可靠性博弈

【背景】 在分布式系统中，消息可靠性一直是核心命题。我们团队在支付对账链路中，曾因 Kafka 的 Exactly-Once 语义与 RocketMQ 的事务消息争议，花了两周验证才确定方案。

【常见分歧】

• 事务消息支持者：全链路事务保证强一致，但牺牲性能与复杂度
• 幂等消费派：用 at-least-once + 唯一标识幂等表，实现最终一致
• 混合派：核心链路用事务消息，异步补偿用幂等

【我的倾向】 目前倾向「核心路径 Exactly-Once + 异步路径幂等」的混合方案：

1. 交易确认用 RocketMQ 事务消息（保证最终一致性）
2. 对账补偿用 Kafka at-least-once + 唯一标识幂等表（降低复杂度）
3. 用 Kafka 事务消息做异步补偿（需处理半事务态）

【想听你的观点】

1. 你们线上如何抉择？
2. 在消息丢失率 <0.01% 的场景下，是否值得为 0.001% 的风险上事务消息？
3. 有没有踩过「事务消息半态丢失」的坑？