简述消息队列在电商系统使用场景以及工作模式
- 2021 年 11 月 18 日
- 筆記
概述
消息队列（Message Queue），是分布式系统中重要的组件，是一种进程间通信或者是同一进程的不同线程的通信方式。和 http 同步协议不同的是，消息队列是一种异步的通信协议，不需要立即获得结果。
消息队列的使用场景
- 异步处理
- 流量控制
- 应用解耦
应用解耦
消息队列的一个作用就是实现系统应用之间的解耦。举例一下电商系统的中的订单系统。
当创建一个订单时：
- 发起支付
- 扣减库存
- 发消息告知用户
- 更新统计数据
这些订单下游的系统都需要实时获得订单数据，随着业务量的增大和业务的变更，有一段时间不需要发消息给客户，或者需要添加功能，每次都需要不断的调式订单系统和下游系统。
引入消息队列后，订单服务在创建订单时发送一条信息到消息队列主题 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
- 每个消息可以被多个队列消费
