简述消息队列在电商系统使用场景以及工作模式

2021-11-18 09:37:45 浏览数 (1)

概述

消息队列(Message Queue),是分布式系统中重要的组件,是一种进程间通信或者是同一进程的不同线程的通信方式。和 http 同步协议不同的是,消息队列是一种异步的通信协议,不需要立即获得结果。

消息队列的使用场景

  • 异步处理
  • 流量控制
  • 应用解耦

应用解耦

消息队列的一个作用就是实现系统应用之间的解耦。举例一下电商系统的中的订单系统。 当创建一个订单时:

  1. 发起支付
  2. 扣减库存
  3. 发消息告知用户
  4. 更新统计数据

这些订单下游的系统都需要实时获得订单数据,随着业务量的增大和业务的变更,有一段时间不需要发消息给客户,或者需要添加功能,每次都需要不断的调式订单系统和下游系统。

引入消息队列后,订单服务在创建订单时发送一条信息到消息队列主题 Order 中,所有的下游都订阅主题Order,这样无论增加、减少下游系统还是下游系统的功能如何变化,订单服务都不需要做更改了,实现了订单服务和下游服务的解耦。

异步处理

异步处理是将很多串行进行的步骤转成异步处理,还是已订单系统为例,下单订单需要创建订单和锁定库存,确定本次请求后马上给用户返回响应,然后把后续请求的数据的都在消息队列,由消息队列异步处理。

这样把五个步骤减少为两个步骤,假设每个步骤处理时间需要500ms,在不考虑网络延迟的情况下:

串行处理: 500 * 5 = 2500ms 并行处理:500 * 2 = 1000ms

系统响应时间缩短一半以上。这样响应速度更快,而且把请求放在后续操作,可以充分利用更多的资源处理请求。 所以我们可以看到,实现异步操作的服务:

  • 更快地返回结果
  • 减少等待时间,提升系统总体性能

流量控制

在购物网站的做一个秒杀活动,平时网站能支撑每秒1000次并发请求,但是电商秒杀一下请求猛增到每秒3000次请求,多出来的请求,可能直接让系统宕机。 所以我们就需要使用消息队列来控制流量,当系统短时间接收到大量请求时,会先将请求堆积到消息队列上,后端服务从消息队列上消费数据,消息队列相对于给后端服务做了一次缓冲。

优缺点

上面的概述总结起来有个三个优点:异步、削峰和解耦。 缺点有以下几个:

  • 系统可用性降低
  • 增加系统复杂度
  • 可能会数据一致性问题,比如数据丢失,数据重复传输

RabbitMQ消息队列五种工作模式

在rabbitmq官网教程上介绍了几种工作模式,

简单(simple)模式

The simplest thing that does something

从上面的示意图看出来 simple 模式有以下几个特征:

  • 只有一个生产者、一个消费者和一个队列
  • 生产者和消费者在发送和接收消息时,只需要指定队列名称,而不需要发送那个 Exchange 交换机。

工作(Work)模式

在多个消费者之间分配任务(竞争消费者模式) 创建一个工作队列,添加多个消费者共同消费工作队列上的任务。每一个消息都给一个消费者消费

发布订阅(Publish/Subscribe)模式

工作模式中每个消息只能被一个消费者消费,发布订阅模式是每个消息同时给多个消费者消费。 上图中的X表示Exchange 交换器,Exchange 类型有:Direct、Topic、Headers和Fanout。

  • 发布订阅用的是 Fanout
  • Fanout 是不需要指定具体的队列名,Exchange 会将消息转发所有的绑定的队列

路由(Routing)模式

路由模式中的交换器类型为 direct,在同一个交换器,由生产者指定指定目标队列。

  • 指定规则按照 RoutingKey 指定
  • 消费者通过 BindingKey 绑定自己接收消息队列
  • 只有 RoutingKey 和 BindingKey 匹配队列才会收到信息

RoutingKey 是生产者指定 Exchange 路由到哪个队列,BindingKey 用于消费者绑定到某个队列

主题(Topic)模式

主题模式是根据通配符绑定队列,其中 * 可以替换任务一个标识符,# 可以替换多个标识符,通配符和名称使用 . 隔开。

  • 主题模式的 Exchange 类型为 topic
  • 每个消息可以被多个队列消费

0 人点赞