第 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 中，我们将所有内容放在一起，其中服务通过消息队列连接并解耦。通过这种方式，架构可以实现更高的吞吐量。
图3 使用消息队列进行限时抢购架构
返回搜狐，查看更多