消息队列入门：为什么系统需要排队

在生活中，排队随处可见：银行取号、食堂打饭、景点检票。系统世界里也一样，当很多请求同时涌来、后台一时处理不过来时，就需要一个地方让请求先排队等一等——这就是消息队列。

一、什么是消息队列
消息队列是一种在系统之间传递消息的中间件。发送方把消息放进队列就可以继续做别的事，不用等接收方处理完；接收方按自己的节奏从队列里一条一条取出消息来处理。队列就像一个有秩序的“暂存区”，既做缓冲，也做转交。

二、生产者与消费者如何配合
生产者是消息的发送者，它只负责把消息投递到队列，不关心消息最终由谁处理；消费者是消息的处理者，它从队列取消息并执行业务逻辑。两者不直接见面：生产者发完消息就走，消费者按自己的速度取消息。常见的配合模式有一对一、发布订阅和竞争消费：一个订单创建的消息，可以只交给库存服务扣减，也可以同时广播给短信服务、积分服务和日志服务；如果积压了很多图片要压缩，还可以让多个消费者一起从同一个队列取任务，并行处理。

三、为什么系统需要排队
第一是异步。用户下单时，真正需要马上完成的是创建订单和扣库存，发短信、加积分可以稍后做。把这些事变成消息丢进队列，用户就不用等它们全部做完，响应更快。第二是解耦。订单服务只管往队列发一条“订单已创建”的消息，不用直接调用短信、积分、物流服务；哪个服务挂了也不影响下单，消息还留在队列里等它恢复；新加一个服务时，只要新写一个消费者去订阅，不用改订单服务的代码。第三是削峰填谷。秒杀时一秒涌入上万请求，直接打到数据库会把系统冲垮；先把请求写进队列，再由消费者按数据库能承受的速度慢慢处理，高峰就被削平了，低谷时继续消化积压的消息，算力也不浪费。

四、RabbitMQ 与 Kafka 的区别
RabbitMQ 是一个经典的消息队列，基于 AMQP 协议，消息路由非常灵活，支持直连、主题、扇出等多种交换机，还有死信队列、延迟队列等企业级特性，延迟低、可靠性强，适合订单、支付回调、任务分发这种“每条消息都不能丢、路由复杂”的业务场景。Kafka 则是一个分布式提交日志，靠 Topic 和分区存放消息，消息消费后不会删除，可以按偏移量回放历史数据，吞吐量可达百万级，适合日志采集、用户行为埋点、实时数仓和流式计算这类“流量极大、需要回放”的数据管道场景。简单判断：要灵活路由、不丢消息、业务复杂，选 RabbitMQ；要极高吞吐、消息回放、流式处理，选 Kafka。很多公司两个都用，Kafka 做大数据管道，RabbitMQ 做业务系统间的异步通信。

五、一个最小使用场景
假设一个电商下单流程：用户下单后，订单服务创建订单、扣减库存，然后往队列里发两条消息——一条给短信服务发“下单成功”短信，一条给积分服务加积分。短信和积分服务各自从队列取消息处理。哪怕短信服务暂时挂了，消息还在队列里，等它恢复后继续取，不会丢失；高峰期消息堆积时，可以横向增加消费者数量来加快处理，或者对消息做限流和降级，优先保证核心链路。

小结
消息队列就是系统里的“排队区”：它让生产者和消费者不用直接见面，用异步省时间，用解耦省维护，用削峰填谷保系统稳定。理解了它，就理解了现代分布式系统最常用的解耦方式之一。下次设计系统时，不妨先问一句：这里需不需要排队？