消息队列应用场景介绍

来源：脚本之家时间：2022-03-26 15:45:00

一、什么是队列

队列（Queue）是一种常见的数据结构，其最大的特点就是先进先出（First In First Out），作为最基础的数据结构，队列应用很广泛。比如火车站排队买票等等。可以用下图表示队列：

其中a1、a2、an表示队列中的数据。数据从队尾入队列，然后从队头出队列。

二、什么是消息队列

消息队列（Message Queue）是一种使用队列（Queue）作为底层存储数据结构，可以用于解决不同进程与应用程序之间通讯的分布式消息容器，也可以称为消息中间件。

目前比较常用的消息队列有ActiveMQ、RabbitMQ、Kafka、RocketMQ、Redis等。

消息队列和队列有什么区别呢？

唯一的区别在于入队列的时候称为生产者，出队列的时候称为消费者。

三、消息队列应用场景

消息队列应用场景非常广泛，下面我们列举比较常见的几个场景

1、分布式场景

1.1、异步处理

一般我们写的程序都是按照顺序执行的（即同步的方式）。比如电商系统中订单的例子，其执行顺序如下：

用户提交订单。订单完成以后增加积分。发生积分变动的短信通知。

可以用下面的流程图表示：

如果按照上面的顺序执行，假如每个服务都需要花费一秒，那么客户端就要花费3秒的时间。对于用户来说，3秒的时间显然是不能忍受的，那么我们该如何解决呢？我们可以使用异步的方式来解决这个问题，看下面一张流程图：

按照这种方式，积分服务和短信服务使用线程异步的方式进行操作，那么客户端只需要花费1秒的时间就可以完成了。但是，这种异步的方式会带来另外的问题：并发量降低。因为积分服务和短信服务都需要在订单服务里面开启线程，开启的线程多了，会导致客户端访问订单服务的并发量降低，可能导致客户端提交订单的实际时间会超过1秒钟。那么如何解决异步带来的问题呢？那就是使用消息队列，看下面的流程图：

在上面的流程中，我们增加了一个消息队列的角色，首先由客户端提交订单，然后把订单写入到消息队列，积分服务和短信服务同时去消费消息队列里面的消息，这种方式不需要订单服务在额外的开启异步线程，客户端可以实现真正的耗时1秒。

1.2、应用解耦

我们还是以电商系统为例进行讲解，先看下面的流程图：

上图的业务逻辑：客户端发起一个创建订单的请求，创建订单的时候，我们要先获取库存，然后在去扣减库存，这样订单系统和库存系统就形成了非常紧密的依赖关系。假如这时候库存系统发生了宕机，由于订单系统依赖于库存系统，这时候订单系统将不能使用。那么如何解决呢？

看下面使用消息队列的流程图：

在上面的流程中，我们加入了消息队列。首先客户端发起创建订单的请求，订单的消息写入到消息队列里面，然后库存系统去消息队列里面订阅消息，最后异步的去更新库存系统。如果库存系统发生了宕机，由于订单系统不直接依赖于库存系统，所以订单系统可以正常的响应客户端的请求。这样就实现了应用解耦。

1.3、流量削峰

对于高并发的系统来说，在访问高峰时，突发的流量就像洪水般涌向应用系统，尤其是一些高并发写操作，随时会导致数据库服务器瘫痪，无法继续提供服务。

而引入消息队列则可以减少突发流量对应用系统的冲击。消费队列就像“水库”一样，拦截上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。

在这方面最常见的例子就是秒杀系统，一般秒杀活动瞬间流量很高，如果流量全部涌向秒杀系统，会压垮秒杀系统，通过引入消息队列，可以有效缓冲突发流量，达到“削峰”的作用。

我们使用秒杀的场景来描述流量削峰，先看下面一张流程图：

在上面的流程中，我们把秒杀服务称为上游服务，订单服务、库存服务、余额服务统称为下游服务。客户端发起秒杀的请求，秒杀服务收到客户端发送的请求以后，创建订单，修改库存，扣减余额，这是秒杀的基本业务场景。

假如下游服务只能同时处理1000个并发请求，上游服务可以处理10000个并发请求，而客户端发起了10000个请求，超出了下游服务可以处理的并发量，所以会导致下游服务发生宕机。这时就可以加入消息队列来解决宕机的问题。看下面加入消息队列的流程图：

我们在上面的流程图中加入了消息队列，描述服务接收到客户端发送的10000个请求以后，把所有的请求都写入到消息队列中，然后下游服务去订阅消息队列里面的秒杀请求，然后在去执行自己的业务逻辑操作。

我们举个简单的例子，上游服务还是能处理10000个并发请求，下游服务还是只能处理1000个并发请求，那么这时候我们在消息队列里面会允许存1000个并发请求。上游的秒杀服务接收到10000个并发请求，而消息队列里面只能存1000个请求，多余的请求就不会存入到消息队列里面，直接返回给客户端提示“系统繁忙，请稍后！”。这就是所谓的流量削峰场景。这是由下游服务可以处理的并发量决定的。由于下游服务只能处理1000个并发请求，所以消息队列里面只能存1000个秒杀，多余的秒杀请求全部返回客户端提示。这样就保证了下游服务的正常响应，不会导致下游服务发生宕机，提高了系统的可用性。