消息队列知识点总结

本文中将会介绍有关于消息队列(后文中统称MQ)的概念、特点以及使用场景等相关知识点。希望这些知识点能够帮助大家更清晰、更准确的利用好MQ这一大利器。如果MQ使用得当，则可以增加工程的可扩展性和数据处理效率；若使用不得当，则反而会加剧工程的结构复杂度以及数据一致性等问题。

笔者也会将自己的理解在文中进行阐述，这也算是在和大家交流心得的一个过程。若文中有错误的理解和概念，请大家及时纠正；吸纳大家的建议，对于我来说也是很重要的学习过程之一。

1.适用场景

在以下三类场景中，通常会选择使用MQ来实现:

1. 数据的异步处理

   即能够协助我们将原本通过

   同步操作实现的逻辑改造为通过异步操作实现的流程

   。凭借着异步并发的优势，异步操作可以更有效的利用现有的计算资源。

   同时，也可用于

   一份数据会被多方使用的场景

   ，例如订阅模型。

2. 系统应用解耦

   即能够用来协助我们拆分复杂的工程，实现

   大工程的功能解耦

   需求。即用来解决服务与服务之间的紧耦合问题。

3. 业务流量削峰

   即能够用来防止短时间内的高流量冲垮后端服务器以及数据库，

   即可用作缓冲层来使用

   。

   适用于那些想防止因短时间内有大量请求而导致服务无法正常工作的场景，即使用MQ来缓存数据。

Tips:

笔者认为可以从上述的适用场景中分析出一些MQ的特性。而这些特性，是可以用来作为判断MQ是否适用于指定场景的判断依据。笔者认为MQ的特性有以下几点:

1. 消息延迟性

   MQ适合那些对于消息处理不追求实时性的场景,

   即可以接受消息延迟处理的场景

   。

1. 业务逻辑异步化

   使用MQ为业务逻辑做异步化之前，要先仔细考量

   相关逻辑是否能够更改为异步方式运行

   。

   往往一些过于关系紧密的逻辑，是不适合改造成异步方式运行的。因为针对于异步处理的回滚是不容易实现的。

   其次，当逻辑改造为异步并发操作后，

   会不会给数据带来不一致性等类似问题

   ，也是需要仔细考量的一点。

1. 数据处理顺序

   MQ只适用于那些

   对于数据处理没有顺序要求

   的业务。

2.架构抽象

对于一个消息队列而言,可以

拆解为四部分：消息、生产者集群、消息队列集群、消费者集群

。消息是从生产者流向消息队列集群，最终再从消息队列集群流向消费者，即生产消费模型。

了解消息队列的架构能够帮助我们更好的认识其优缺点，以便更正确的使用MQ。后续篇章会基于该抽象来分别对架构中的每一部分进行介绍。

2.1 消息

消息其本质是一条数据

，这类数据被消息队列封装后也被称为一条消息。该条消息只能发送到其消息队列集群内部的一个分区队列中。因此只需按照一定的策略从多个队列中选择一个队列即可。

Tips:

笔者认为，消息作为消息队列模型中的数据载体，是贯穿整个消息队列工作流程的。消息队列的工作流程也可以看为是消息的生命周期转换过程，即经历了"消息诞生-消息流转-消息处理"这一生命周期。

消息的数据结构也会影响到整个工作流中的部分细节。例如可以通过消息中某些字段的值来对消息进行精准路由等。

因此，对于消息的数据结构设计也是使用好MQ的一个重要因素。

2.2 生产者集群

生产者集群的主要功能为生产数据，即产出消息

。通常也称为数据的输入提供方。

对于生产者的实现方式，主要有以下两种:

1. 客户端

   在大多数场景中，生产者是作为客户端的方式存在。

2. 服务端

   在支持事务消息的消息队列中，生产者会被设计为服务端，实现事务消息这一特性。

Tips: 因为消息队列集群需要通过调用生产者的接口来获取本地事务的执行情况，以用来判断后续应选择什么样的消息处理机制应。

生产者集群中往往会有多个生产者同时工作，以提高数据的产出速度。消息队列集群内部也会有多个分区队列，所以在

多个生产者在发送数据时通常会存在负载均衡的一些策略

。常见的有按 key hash、轮询、随机等方式。

2.3 消息队列集群

消息队列集群的主要功能为存储消息、过滤消息和分发消息。

2.3.1 存储消息

顾名思义，消息队列是可以用来

保存消息数据

的，但这里的保存是

暂存

的含义。即消息不应长期堆积在消息队列中，不应使用消息队列作为消息数据持久化的手段。

同时，一个消息队列吞吐量的高低、性能优劣都和它的存储模型脱不开关系。

2.3.2 过滤消息

过滤消息只指消息队列可以通过一定的规则或者策略进行消息的过滤，

该项能力通常也被称为消息路由

。

消息路由一般会影响消息数据在消息队列集群中的分布情况。例如可以通过利用这点，将重要消息路由到可靠性较高的集群节点上；或将按照地理位置将消息路由到邻接的集群节点上，使得消费者能够以最小的网络延迟消费到数据。

2.3.3 分发消息

分发消息是指消息队列通常需要

将消息分发给处理同一逻辑的多个消费者处理或者处理不同逻辑的不同消费者处理

。

分发消息可以说和消费者模型相挂钩

，因为不同的消费者模型有着不同的数据获取方式。此外绝大部分的消息队列也都支持对消息进行分类，分类的标签称为topic（主题），一个topic中存放的是同一类消息。

2.4 消费者集群

消费者集群的主要功能为处理消息数据。消费者也可以看做消息队列中数据的输出方。

在章节2.3.3中提到过，消息队列分发消息的方式是和消费者模型有密切关系的。这里的模型通常是指消费者的数据方式和消费者模型，本章节中会通过这两方面来介绍消费者集群。

2.4.1 消息获取方式

消费者通常有两种方式从消息队列中获取数据：推送（push）数据、拉取（pull）数据。这里提供一些这两种方式各自的优缺点：

1. 消息实时性强

   因为消息队列拿到消息后就会马上推送给相应的消费者。

2. 消费者资源利用不充分

   这种方式下，消息流转的速率是由消息队列控制的。此时，若所有的消费者都有这相同的消息处理速度，则没有任何资源浪费。但实际情况中，消费者之间往往会因为计算资源等其他因素而导致每一个消费者的消息处理速度不用。又因为消息发送速率是相同的，则此时就有可能会发生有些消费者消费的快从而出现等待消息的情况。

3. 消耗存储资源

   由于2中所描述的问题，会导致消息队列需要保存因消费者消费速度慢而产生的堆积消息数据。同时如果消费失败，则消息队列还需要保存这些失败消息数据以用于后续的重试。因此会消耗消息队列的一部分存储资源。

1. 消息实时性弱

   消费者需要定期询问消息队列是否有消息可以进行消费，是一个被动操作。

2. 消费者资源利用充分

   在此方式下，消息的处理速度是由消费者控制的。因此消费者可以根据自身的处理能力，选择合适的消费速度来进行消息处理。消费快的消费者就会多消费消息，而消费慢的消费者会少消费消息。

3. 消耗网络资源

   如1中所描述，消费者需要和消息队列之间建立长连接，不间断的询问消息队列是否有新消息可以进行消费。即会消耗消息队列的网络资源。

2.4.2 消费者模型