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

概述

消息队列（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
• 每个消息可以被多个队列消费