为什么需要消息队列：解耦、异步与削峰

引入消息队列，通常是为了处理三个问题：解耦服务关系、缩短同步请求链路、缓冲流量洪峰。

解耦#

没有 MQ 时，A 系统需要直接调用 B、C、D 等系统，并处理每个下游的超时、失败和重试。使用发布订阅后，A 只负责把消息写入 MQ，需要数据的系统自行消费；新增或移除下游不会修改 A 的调用代码。

如果一次请求同时等待本地写库和多个下游写库，延迟会变成各步骤耗时之和。改为先写入 MQ 后立即返回，耗时较长的下游操作由消费者异步完成，用户请求链路就不必同步等待全部工作。

当流量从每秒几十个请求突然升到几千个时，后端数据库可能被瞬时流量压垮。MQ 先承接高峰，消费者按数据库能够承受的速度拉取处理；代价是消息会暂时积压，因此必须监控积压量和恢复速度。

先区分是流量过大还是消费者故障：前者可临时扩容消费者、增加分区；后者要先修复 Bug，并视情况转存消息，待修复后重新处理。

生产者要确认消息投递成功，消费者处理必须幂等，并用定时任务扫描异常数据做补偿。例如库存扣减失败时，可以重试“已下单未扣库存”的订单，或取消订单并退款。

1
Kafka → Topic → Partition → Consumer → 数据库

Topic 是消息分类，Partition 用于并行存储和消费，Consumer 是处理消息的实例，Consumer Group 则由多个实例共同消费一个 Topic。