同步请求死磕耗时任务就是自寻死路：聊聊 MQ 的交付陷阱与架构选择

后端如果还把图片缩放、报表生成这种脏活累活全塞进同步请求里，等用户等到怀疑人生，你的系统早晚会被突发流量冲垮。我之前也犯过这种“求稳”的蠢，总觉得同步逻辑最直接，结果就是 DX（开发体验）极差，系统吞吐量低得可怜。

真正的解耦逻辑应该是让 Producer 把任务往队列里一扔就撤，别在那傻等。但这不代表加个消息队列就能躺平，如果你搞不清楚 Delivery Guarantees 的代价，坑只会更多：

At-most-once：追求极致低延迟，但丢包率你得自己认。

At-least-once：这是目前最主流的方案。虽然能保证消息不丢，但重复投递是常态。如果你在处理扣款或订单逻辑时没写好幂等性（Idempotency）校验，那重复执行一次就是灾难。

Exactly-once：听起来很美，但分布式环境下实现这玩意儿的性能损耗大得惊人。

另外，别把 Queue 和 Pub/Sub 搞混了。做点对点的任务分发，老老实实用 Message Queue；如果是想让库存、计费、通知这帮服务同时监听同一个事件，那是 Pub/Sub 的活儿。

别光看理论，直接看这两个工业级实现：
https://github.com/rabbitmq/rabbitmq
https://kafka.apache.org/

别再用那种“一竿子插到底”的低效架构了，早点升级你的思维模型。