请求太多要排队：消息队列如何拯救高并发系统

在双十一秒杀等极端场景下，数十万人同时下单，后端系统往往直接崩溃。这是典型的流量保护缺失导致的后果。

为什么系统会崩？因为后端的处理能力存在物理上限。每秒能处理的请求数量是有“天花板”的，一旦请求量超过这个阈值，系统便无法承载。

解决这一问题的核心思路是：让请求排队，而不是一窝蜂地涌入。 这正是消息队列（Message Queue）要解决的问题。

奶茶店类比：理解消息队列

我们可以用一个生活中的场景来类比：

想象一家奶茶店，店里只有两名店员。如果突然来了 50 个人，全部挤在窗口大喊“我要一杯”，店员根本应付不过来，现场会乱成一团，甚至导致服务瘫痪。

但如果店里有一台取号机：

1. 顾客进店先取号，按顺序等待。
2. 店员按照自己的节奏制作奶茶。
3. 做完一杯，叫下一个号。

无论同时来多少人，店员都不会崩溃，因为压力被缓冲了。消息队列就是这个“取号机”。

消息队列的工作原理

在技术实现上，消息队列的工作流程如下：

• 请求进入队列：用户发出的请求不直接打到后端服务器，而是先进入消息队列。
• 后端按需消费：后端服务根据自己的处理能力，从队列中一条一条地取出请求并执行。

这种机制带来了三个核心好处：

1. 异步处理（Asynchronous Processing）

用户发出请求后，不需要等待所有逻辑处理完毕。系统可以先返回“已收到，处理中”的响应，而实际的复杂逻辑在后台慢慢执行。

典型场景：

• 用户下单成功，页面立即显示成功。
• 背后的短信通知、积分增加、库存扣减等逻辑在后台异步执行。
• 结果：用户感知不到延迟，但短信可能会延迟几秒到达。

2. 削峰填谷（Peak Shaving）

当流量高峰来临时，请求先堆积在队列中。高峰过去后，系统再慢慢消化这些积压的请求。

• 缓冲区作用：队列像一个蓄水池，把瞬间涌来的巨大压力平摊开来。
• 保护核心组件：防止瞬时高并发直接砸向数据库和业务逻辑层，避免系统过载。

3. 解耦（Decoupling）

发消息的一方（生产者）和处理消息的一方（消费者）互相不直接依赖。

• 独立性：一方出问题，不会立即影响另一方。
• 灵活性：你可以独立扩展生产者或消费者的数量，而无需修改对方的代码。

主流消息队列工具

目前业界常用的消息队列工具有：

• RabbitMQ
• Kafka
• RocketMQ

在国内项目中，RocketMQ 和 Kafka 的使用率较高。

注意事项：不要为了用而用

虽然消息队列强大，但引入它也会带来副作用：

1. 系统复杂度增加：需要维护额外的中间件。
2. 消息可靠性问题：消息可能重复消费，也可能丢失，都需要额外的代码逻辑来处理（如幂等性设计、重试机制等）。

建议： 对于新手项目或流量不大的场景，不一定需要引入消息队列。请根据实际业务需求决定，避免过度设计。

你用过消息队列吗？使用的是哪种工具？欢迎在评论区交流。