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

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

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

文章插图
在星巴克,收银员接受订单并收取款项,然后在咖啡杯上写下顾客的名字,交给下一个步骤 。制作咖啡的人拿起订单和杯子,然后制作咖啡 。然后顾客在柜台上取走咖啡 。这三个步骤是异步进行的 。收银员只是将订单以咖啡杯的形式放下,并不等待完成 。制作咖啡的人只是将完成的咖啡放在柜台上,并不等待顾客来取 。
当您在星巴克下订单时,收银员接受订单并在杯子上写下您的名字,然后转向下一个顾客 。然后咖啡师拿起杯子,准备您的饮品,然后留下供您取走 。这个过程之所以美妙,是因为每个步骤都是独立运作的 。这很像一个异步系统 。
为什么我们需要消息队列?

文章插图
 图1 星巴克作为消息队列的类比
这种异步处理,每个步骤都不必等待前一个步骤完成,显著增加了系统的吞吐量 。例如,收银员不必等待您的饮品制作完成后才接受另一个订单 。
消息队列的一个示例现在,让我们将焦点转向一个真实世界的例子:电子商务中的限时抢购 。由于用户活动激增,限时抢购可能会给系统带来压力 。为了应对这种需求,采用了许多策略,而消息队列通常在后端优化中发挥关键作用 。
一个简化的电子商务限时抢购架构如图2所示 。
  • 步骤1和2:顾客向订单服务下订单 。
  • 步骤3:在处理付款之前,订单服务保留所选的库存 。
  • 步骤4:然后订单服务将支付指令发送到支付服务 。支付服务会扇出到3个服务:支付渠道、通知和分析 。
  • 步骤5.1和6.1:支付服务将支付指令发送到支付渠道服务 。支付渠道服务与外部PSP(支付服务提供商)进行通信,以完成交易 。
  • 步骤5.2和6.2:支付服务向通知服务发送通知,通知服务然后通过电子邮件或短信向顾客发送通知 。
  • 步骤5.3:支付服务向分析服务发送交易详细信息 。

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

文章插图
图2 一个简化的电子商务限时抢购架构
这里的一个关键点是,在限时抢购活动中,无缝的用户体验至关重要 。为了在高流量情况下保持服务的响应能力,可以在多个阶段集成消息队列,以确保性能最佳 。
消息队列的优势扇出支付服务将数据发送到三个下游服务,用于不同的目的:支付渠道、通知和分析 。这种扇出方法就像有人在房间里大声喊话;谁需要听到,就听到了 。生产者只需将消息放在队列中,而消费者可以按照自己的节奏处理消息 。
(1) 异步处理
借用星巴克的类比,就像收银员不必等待咖啡制作完成一样,订单服务也不必等待支付完成 。支付指令被放置在队列中,一旦完成,顾客就会收到通知 。
(2) 速率限制
在限时抢购活动中,可能会有数以万计的并发用户同时下订单 。在满足渴望购买的顾客和保持系统稳定之间取得平衡非常重要 。一种常见的方法是在特定的时间范围内限制进入的请求数量,以匹配系统的容量 。多余的请求可能会被拒绝或要求在短时间延迟后重试 。这种方法确保系统保持稳定,不会被压垮 。对于成功通过的请求,消息队列确保它们被高效有序地处理 。如果系统的某个部分暂时滞后,订单不会丢失 。它会在队列中保持,直到可以处理为止 。这确保了即使在压力下也能保持流畅的流程 。
(3) 解耦
我们的设计在多个地方使用了消息队列 。总体架构与图2中呈现的简化版本不同 。服务之间通过定义良好的消息接口进行交互,而不是紧密依赖彼此 。每个服务都可以独立进行修改和部署 。每个组件可以使用不同的编程语言进行开发 。这为架构设计带来了灵活性 。
(4) 横向扩展
由于服务被解耦,我们可以根据需求独立地进行扩展 。每个服务可以在不同的能力范围内提供服务,因此我们可以根据其计划的每秒查询数(QPS)或每秒事务数(TPS)进行扩展 。
(5) 消息持久性
消息队列还可以用作存储消息的中间件 。如果上游服务崩溃,下游服务始终可以从消息队列中获取消息进行处理 。通过这种方式,恢复功能从每个服务中移出,并成为消息队列的责任 。


推荐阅读