一文讲解为什么我们需要消息队列？
在本期中，我们将深入探讨一个广泛使用的中间件：消息队列。
消息队列具有很长的历史。它们通常用于不同系统之间的通信。图 1 通过将消息队列与星巴克的工作方式进行比较，说明了消息队列的概念。
在星巴克，收银员接过订单并收钱，然后他们在咖啡杯上写下顾客的名字，然后交给下一步。咖啡机拿起订单和杯子并煮咖啡。然后，顾客在柜台拿起咖啡。这三个步骤以异步方式工作。收银员只是以咖啡杯的形式放下订单，而不是等待订单完成。咖啡机只是将完成的咖啡放在柜台上，而不是等待顾客拿起它。
当您在星巴克下订单时，收银员接过订单并在杯子上写下您的名字，然后转向下一位顾客。然后咖啡师拿起杯子，准备您的饮料，然后留给您收集。这个过程的美妙之处在于每个步骤都是独立运行的。它很像一个异步系统。
这种异步处理（每个步骤都不必等待前一个步骤完成）显著提高了系统的吞吐量。例如，收银员在接受另一个订单之前不会等待您的饮料制作完成。
现在，让我们将注意力转移到一个真实的例子上：电子商务中的限时抢购。由于用户活动的激增，限时抢购可能会给系统带来压力。许多策略都用于管理这种需求，消息队列通常在后端优化中起着关键作用。
图 2 列出了简化的电子商务限时抢购架构。
第 1 步和第 2 步：客户向订单服务下订单。
第 3 步：在处理付款之前，订单服务会保留所选库存。
第 4 步：然后，订单服务向支付服务发送付款指令。支付服务分为 3 种服务：支付渠道、通知和分析。
步骤5.1和6.1：支付服务向支付通道服务发送支付指令。支付渠道服务与外部 PSP（支付服务提供商）通信以完成交易。
步骤 5.2 和 6.2：支付服务向通知服务发送通知，然后通知服务通过电子邮件或短信向客户发送通知。
步骤 5.3：付款服务将交易详细信息发送到分析服务。
这里的一个关键要点是，在限时抢购期间，无缝的用户体验至关重要。为了在高流量的情况下保持服务响应能力，可以在多个阶段集成消息队列，以确保最佳性能。
消息队列的优点
- 扇出
支付服务出于不同的目的将数据发送到三个下游服务：支付渠道、通知和分析。这种扇出方法就像有人在房间里喊一条消息;谁需要听到它，谁就听。生产者只需将消息放入队列中，消费者就会按照自己的节奏处理消息。
- 异步处理
借鉴星巴克的类比，就像收银员不等待咖啡制作完成一样，订单服务也不会等待付款完成。付款指令被放置在队列中，一旦最终确定，就会通知客户。
- 速率限制
在限时抢购中，可以有数以万计的并发用户同时下订单。在满足热切的客户和保持系统稳定性之间取得平衡至关重要。一种常见的方法是在特定时间范围内限制传入请求的数量，以匹配系统的容量。多余的请求可能会被拒绝或要求在短暂延迟后重试。这种方法可确保系统保持稳定，不会不堪重负。对于通过的请求，消息队列可确保它们得到高效且有序的处理。如果系统的某一部分暂时滞后，则订单不会丢失。它被保留在队列中，直到可以处理为止。这确保了即使在压力下也能平稳流动。
- 解耦
我们的设计在各个地方使用消息队列。整体架构与图 2 中所示的简化版本不同。服务使用定义良好的消息接口相互交互，而不是紧密依赖彼此。每个服务都可以独立修改和部署。每个组件都可以用不同的编程语言进行开发。这为架构设计带来了灵活性。
- 水平可扩展性
由于服务是解耦的，我们可以根据需求独立扩展它们。每个服务都可以以不同的容量提供服务，因此我们可以根据其计划的 QPS（每秒查询数）或 TPS（每秒事务数）进行扩展。
- 消息持久性
消息队列还可以用作存储消息的中间件。如果上游服务崩溃，下游服务始终可以从消息队列中选取消息进行处理。这样，恢复功能就从每个服务中移出，并成为消息队列的责任。
- 批处理
有时在处理流程中，我们需要对数据进行批处理才能得到摘要。例如，当支付服务向分析服务发送更新时，分析服务不需要执行实时更新，而是设置一个滚动窗口以批量处理。批处理是下游服务的需求，因此不需要支付服务知道它，只需将消息放入队列即可。
- 消息排序
在限时抢购中，库存商品数量有限。例如，限时抢购仅提供 10 部 iPhone，但有超过 10,000 名用户下订单。我们如何决定订单？有一个消息队列来保存所有订单将有一个自然的顺序：队列中的前 10 个将获得 iPhone。
在图 3 中，我们将所有内容放在一起，其中服务通过消息队列连接并解耦。通过这种方式，架构可以实现更高的吞吐量。
