为什么我们需要消息队列？

在这期中，我们将深入探讨一种广泛使用的中间件：消息队列。

消息队列有着悠久的历史，它们经常用于不同系统之间的通信。图1通过将其与星巴克的工作方式进行比较，阐述了消息队列的概念。

在星巴克，收银员接受订单并收取款项，然后在咖啡杯上写下顾客的名字，交给下一个步骤。制作咖啡的人拿起订单和杯子，然后制作咖啡。然后顾客在柜台上取走咖啡。这三个步骤是异步进行的。收银员只是将订单以咖啡杯的形式放下，并不等待完成。制作咖啡的人只是将完成的咖啡放在柜台上，并不等待顾客来取。

当您在星巴克下订单时，收银员接受订单并在杯子上写下您的名字，然后转向下一个顾客。然后咖啡师拿起杯子，准备您的饮品，然后留下供您取走。这个过程之所以美妙，是因为每个步骤都是独立运作的。这很像一个异步系统。

图1 星巴克作为消息队列的类比

这种异步处理，每个步骤都不必等待前一个步骤完成，显著增加了系统的吞吐量。例如，收银员不必等待您的饮品制作完成后才接受另一个订单。

消息队列的一个示例

现在，让我们将焦点转向一个真实世界的例子：电子商务中的限时抢购。由于用户活动激增，限时抢购可能会给系统带来压力。为了应对这种需求，采用了许多策略，而消息队列通常在后端优化中发挥关键作用。

一个简化的电子商务限时抢购架构如图2所示。

步骤1和2：顾客向订单服务下订单。

步骤3：在处理付款之前，订单服务保留所选的库存。

步骤4：然后订单服务将支付指令发送到支付服务。支付服务会扇出到3个服务：支付渠道、通知和分析。

步骤5.1和6.1：支付服务将支付指令发送到支付渠道服务。支付渠道服务与外部PSP（支付服务提供商）进行通信，以完成交易。

步骤5.2和6.2：支付服务向通知服务发送通知，通知服务然后通过电子邮件或短信向顾客发送通知。

步骤5.3：支付服务向分析服务发送交易详细信息。

图2 一个简化的电子商务限时抢购架构

这里的一个关键点是，在限时抢购活动中，无缝的用户体验至关重要。为了在高流量情况下保持服务的响应能力，可以在多个阶段集成消息队列，以确保性能最佳。

消息队列的优势

扇出

支付服务将数据发送到三个下游服务，用于不同的目的：支付渠道、通知和分析。这种扇出方法就像有人在房间里大声喊话；谁需要听到，就听到了。生产者只需将消息放在队列中，而消费者可以按照自己的节奏处理消息。

异步处理

借用星巴克的类比，就像收银员不必等待咖啡制作完成一样，订单服务也不必等待支付完成。支付指令被放置在队列中，一旦完成，顾客就会收到通知。

速率限制

在限时抢购活动中，可能会有数以万计的并发用户同时下订单。在满足渴望购买的顾客和保持系统稳定之间取得平衡非常重要。一种常见的方法是在特定的时间范围内限制进入的请求数量，以匹配系统的容量。多余的请求可能会被拒绝或要求在短时间延迟后重试。这种方法确保系统保持稳定，不会被压垮。对于成功通过的请求，消息队列确保它们被高效有序地处理。如果系统的某个部分暂时滞后，订单不会丢失。它会在队列中保持，直到可以处理为止。这确保了即使在压力下也能保持流畅的流程。

解耦

我们的设计在多个地方使用了

消息队列。总体架构与图2中呈现的简化版本不同。服务之间通过定义良好的消息接口进行交互，而不是紧密依赖彼此。每个服务都可以独立进行修改和部署。每个组件可以使用不同的编程语言进行开发。这为架构设计带来了灵活性。

横向扩展

由于服务被解耦，我们可以根据需求独立地进行扩展。每个服务可以在不同的能力范围内提供服务，因此我们可以根据其计划的每秒查询数（QPS）或每秒事务数（TPS）进行扩展。

消息持久性

消息队列还可以用作存储消息的中间件。如果上游服务崩溃，下游服务始终可以从消息队列中获取消息进行处理。通过这种方式，恢复功能从每个服务中移出，并成为消息队列的责任。

批处理

在处理流程中，有时我们需要对数据进行批处理以获得摘要。例如，当支付服务向分析服务发送更新时，分析服务不需要执行实时更新，而是设置一个滚动窗口以批处理处理。批处理是下游服务的要求，因此支付服务不需要知道它，只需将消息放入队列中。

消息排序

在限时抢购中，库存数量有限。例如，限时抢购只提供10部iPhone，但有超过10,000名下订单的用户。我们如何决定订单的顺序呢？通过使用消息队列来保留所有订单，将会自然形成一个顺序：队列中的前10个订单将获得iPhone。

在图3中，我们将所有内容整合在一起，服务通过消息队列连接并解耦。这样，架构可以实现更高的吞吐量。

图3 在限时抢购架构中使用消息队列

希望这篇文章对你们有所帮助~ 日更不易,喜欢的话欢迎点赞、收藏、关注哈