消息队列基础篇：异步、解耦与削峰
消息队列不是为了让系统变复杂，而是为了解决同步调用里的耦合、峰值流量、失败重试和事件分发问题。
消息队列基础篇：异步、解耦与削峰
消息队列最常见的出现场景，是一个服务不想、不能、或者不应该同步等待另一个服务完成工作。
比如用户下单成功后，系统可能要发短信、更新积分、写行为日志、刷新推荐画像、同步报表。如果所有动作都在下单接口里同步完成，下单链路会变慢，也会因为非核心服务故障影响核心交易。
消息队列把“现在必须完成”和“稍后可以完成”的工作拆开。
消息队列解决什么问题
第一个问题是异步。生产者把消息写入队列后就可以返回，消费者之后慢慢处理。
第二个问题是解耦。订单服务不需要知道短信服务、积分服务、报表服务的具体地址和调用方式。它只需要发布一个 OrderCreated 事件。
第三个问题是削峰。秒杀活动里，下单请求可能瞬间暴涨。队列可以先把请求堆住，让消费者按可承受速度处理。
第四个问题是广播。同一个业务事件可以被多个系统订阅，各自做自己的事。
消息队列不解决什么问题
消息队列不能自动保证业务正确。重复消费、乱序、消息丢失、消费失败，都要靠架构和代码处理。
消息队列也不能代替数据库事务。它可以帮助系统实现最终一致，但不能让跨服务写入天然强一致。
消息队列更不是性能银弹。引入 MQ 后，多了 Broker、网络传输、序列化、重试、监控和运维成本。没有异步和解耦需求时，直接同步调用反而更简单。
一个最小消息模型
一条业务消息通常至少包含这些字段：
{
"event_id": "evt_10001",
"event_type": "OrderCreated",
"aggregate_id": "order_10001",
"occurred_at": "2026-05-17T21:10:00+08:00",
"payload": {
"order_id": "order_10001",
"user_id": "user_90001",
"amount": 199.00
}
}
event_id 用于去重，event_type 表示事件类型，aggregate_id 可以用来保证同一业务对象的顺序，payload 才是真正的业务数据。
MQ 的基本角色
生产者负责发送消息。Broker 负责接收、持久化、分发消息。消费者负责处理消息。
Producer -> Broker -> Consumer
在真实系统里，还会有 Consumer Group、Topic、Queue、Partition、Offset、Ack、Retry、Dead Letter Queue 等概念。它们不是为了堆术语，而是为了处理扩展性、可靠性和失败恢复。
小结
消息队列适合处理异步、解耦、削峰和事件广播。它让核心链路更短，让下游系统可以独立扩展。
但 MQ 引入的是“可控复杂度”，不是“消除复杂度”。使用 MQ 后，必须正面处理可靠投递、幂等消费、顺序性、重试和监控。