Exactly-Once语义的代价：高吞吐场景下如何平衡消息可靠性与系统性能？

【背景】 在Kafka 3.5 + Spring Boot 3.2 + MySQL 8.0的架构中，我们曾为支付回调链路设计过「at-least-once + 幂等表」方案（参考id=1563），但随着业务量突破50万TPS，发现单条消息需调用90s外的外部API时，Exactly-Once的分布式事务开销导致吞吐量下降37%。

【常见分歧】

1. 『必须用Exactly-Once』派：认为业务强一致性是底线（如金融场景）
2. 『妥协方案』派：接受at-least-once + 幂等消费，通过消息重放窗口（参考id=1563）控制重复率
3. 『分层处理』派：核心链路用Exactly-Once，非核心链路降级为at-least-once

【我的倾向】 在90%的业务场景中，我更倾向『妥协方案』：

• 用Kafka的id=1598提到的「at-least-once + 幂等表」模式
• 设置5分钟的幂等窗口（参考id=1563）
• 通过消息重放率监控（参考id=1590的性能验证方法）
• 对关键业务做兜底事务消息（如支付确认）

【想听你的实践】 在以下场景中你们如何取舍？

1. 高吞吐（>10万TPS）但允许0.5%重复率的场景
2. 业务强一致性要求但下游系统不稳定的情况
3. 如何用监控指标（如重放率、消息堆积）量化可靠性成本？