消息队列和应用工具产品体系-消息队列 Rocket 版的主要功能

开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：消息队列和应用工具产品体系-消息队列 Rocket 版的主要功能】

课程地址：https://edu.aliyun.com/course/3112075/lesson/19039

消息队列和应用工具产品体系-消息队列 Rocket 版的主要功能

内容介绍

一、 RocketMQ产品功能概览

二、RocketMQ内部架构

三、RocketMQ 消息收发模式

四、RocketMQ 消息类型

五、RocketMQ 全局顺序

六、RocketMQ 分区顺序

七、RocketMQ 三种发送方式

八、RocketMQ 集群消费模式

九、RocketMQ 广播消费模式

十、 RocketMQ 消息重试

十一、 RocketMQ 多协议接入

十二、 RocketMQ 消息轨迹-快速定位问题

 

一、RocketMQ 产品功能概览

 

 

上面这张图列出了 Rocket 的主要产品功能和特性。相比较于用户用开源 RocketMQ 自行搭建服务云托管版的 RocketMQ 在阿里云的多个地提供了高可用消息云服务。当地域内采用多机房部署，可用性极高，即使整个机房不可用，仍然可以为消息应用提供消息发布服务。开发者可以将部署在阿里云ECS企业自建人或嵌入到移动端物联网设备中，与 RocketMQ 建立连接并进行消息收发。同时，本地开发者还可以通过工宝介入 RocketMQ 服务进行消息收发。

在外部管理台中， RocketMQ 提供了丰富的管理功能。全球消息，路由重置消费等。能相比较于开源版本，开发者使用云托管版本使产品特点会更加丰富，技术支持会更加到位，而运维和错误调试的成本则大大降低。关于给 RocketMQ 的计算计费方式，实力类型，接入方式，消息类型和收发模式等内容在后面的课程我们会为大家一一进行介绍。

二、RocketMQ 内部架构

在介绍 RocketMQ 的具体功能之前，我们先来看一下它的内部结构。 

 

 

RocketMQ 内部采用了类似于微服务的架构进行设计。

首先， RocketMQ 内部有一个名为服务集群注册中心，该服务集群注册中心本身并不提供消息的发送和订阅服务，但是，他可以为实际提供消息订阅发布的实力提供服务注册功能，而broker才是真正提供消息订阅发布的服务组件。当broker上线之后，会向内注册自己。当消息产生者需要发送消息时，会先向name请求broker列表，在获得broker列表后，会选择一个或几个broker实例推向进行消息的发布。同样的，消费者也是通过类似的流程从内者内中获取broker，然后接收消息。由此可见，其中保存的数据量非常小，地址信息因此进行集群化部署就变得非常容易。broker都是以集群的方式进行部署，就避免了系统中的单点的存在，提高了整个系统的可用性。以上就是 RocketMQ 内部结构的简单说明，希望同学们通过对 RocketMQ 架构的学习，加针对微服务下高可用设计的了解。

 

三、RocketMQ 消息收发模式

接下来我们为大家介绍 RocketMQ 中最重要的功能消息收发，

 

 

RocketMQ 采用的是发布订阅者模型，在这里我们先介绍一下发布订阅者模型。发布订阅者模型就是系统中的消息产生和消息的接收处理功能。模块并不直接的发生调用或者耦合，而是通过一个消息转发者进行关联。消息发布者当有事件需要产生时，只是向中间模块发送消息。发送成功后立刻返回，而不关心消息被处理，以及消息被谁处理，而消息的订阅者同消息转发者中获得消息，并不关心消息从何而来，由谁发送。同时发布定位者模型中消息的生产者和消息的消费者都可以为多个，即消息可以由多个生产者产生。同时可以一条消息由多个订阅者消费，而这之间的关联关系全部都由消息转发者负责处理。

以图为例，在 RocketMQ 中如果使用，如果需要使用消息服务，首先需要创建一个，这个就起到了消息转发者作用，左边的消息生产者集群有多个消息生产者组成，当他们有消息需要处理时，会发送消息向右边的消息。消费者集群也是由多个消费者组成。他们不但可以从一个中接收消息，甚至可以多联多同时接受多个匹配的消息推送。而消息生产者集群和消息消费者集群并不知道对方的存在，也不关心对方的存在，他们只和匹配对象进行关联。

 

四、RocketMQ 消息类型

 

 

上面为大家讲解了 RocketMQ 的消息收发最基本模式，在的消息收发中 RocketMQ 支持四种消息类型，包括普通消息，定时延时消息，顺序消息和事务消息。其中，普通消息没有特殊属性，逻辑上是沿用上页讲到的消息收发模式进行处理。而定时延时消息则是在普通消息的基础上加入了定时发送功能。

消息在发送后并不会马上进行投递，而是根据设定的时间投递给消费者，适合用于执行延迟操作的任务或定时执行的任务。比如定时抢购，下单后过一段时间内未付款则关闭订单等功能。顺序消息是指 RocketMQ 提供了一种严格按照顺序进行消息发送和消息消费的消息类型，适合于业务要求比较严格的场景，在下面，我们会为大家进行详细的讲解。而事务消息则是指 RocketMQ 提供了分布式事务处理，通过 RocketMQ 事务消息能够达到分布式事务的最终一致性。这部分内容涉及到的知识点较为复杂，我们将在以后阶段的课程中为大家进行详细的讲解。

 

五、RocketMQ 全局顺序

 

 

接下来我们为大家重点介绍一下顺序消息 RocketMQ ，这是两种顺序消息模式。第一种顺序消息模式是全局顺序消息，在全局顺序消息模式下，同一个Topic内无论有多少个消息，生产者所有的消息严格按照FIFO原则，也就是严格按照先进先出原则消息进行发布。在这种模式下，消息的发送采用了轮群的方式进行，也就是一个实例，发送成功后，下一个实例才可以发送，这样避免了多个实例共同发送消息时导致了消息顺序混乱。

同时，因为消息速度不同，导致会出现后接收的消息有可能被先处理完的情况，从而导致消息处理的顺序错乱。因此，消息的消费者集群中，不论有多少个消费者，实际上是工作在同一时间工作的集群时间的，实际上同一时间工作的消费者实力也只有一个。因此，如果想提高消息的处理吞吐率，只能尽量优化处理流程的方式。由此可见，全局实际上可以认为是一种一对一的消息发送模式，这种工作模式吞吐效率并不高。

同时，如果消息消费者出现卡死等异常情况，则所有的消息都会积压，因此只适合金融交易等极少数的场景。例如，在外汇交易中，以人民币兑换美元为例，在价格相同的情况下，所有的交易要严格按照先处理的原则进行。在这种情况下，就可以按照FIFO的方式进行消息的发布和消费。

 

六、RocketMQ 分区顺序

 

第二种顺序消息模式是分区顺序消息，在分区顺序消息模式下，每个消息除了原有的字段之外，还会加入一个新的字段作为分区字段。在设定了后，分区消息的处理公式变成在同一个消息采用和分区采用和全局分区消息一样的处理流程，也就是严格按照原则进行消息的发送和消费，同一时间，只能有一个实力可以进行消息的发送或者消费。但是，与全局顺序消息不同的是，在不同的时间之间的消息则可以互相不受影响。有多个实例交叉处理，这样就大大提高了整个系统的吞吐量。以电商场景为例，一般来讲，我们会将用户这样设置之后同一个用户的操作流程，如创建订单消息，订单支付消息，订单退款消息，订单物流消息到都会按照先后顺序严格的进行发布。核心订阅，防止用户操作，防止用户操作消息数据混乱导致了业务异常。虽然单个用户的消息只能单一实例来处理，但是由于高发场景下用户的数量非常多。在实际的开发，在实际情况中，并不会出现消费实力等待消息消费的情况。在阿里巴巴集团内部，电商系统均使用此类分区顺序消息，既保证业务的顺序，又保障业务的高性能。

 

七、RocketMQ 三种发送方式

 

 

接下来我们再来讲讲中的消息发送方式，RocketMQ 中共有三种消息发送方式，分别是可靠的同步发送，可靠的异步发送和单向发送。下面我们分别来为大家做一个介绍。

首先是可靠的同步发送方式，这是一种最常见的消息发送方式。有上可知，它是指消息发送方发出一条消息后，会在收到消息队列的发送处理结果之后，再发送下一条消息的通讯方式，这种方式的特点是程序开发简单，可靠性高，容易理解，一般用于重要的邮件发送短信，发送营销通知的。但是它的缺点是，如果同时需要发送大量的消息则需要等待较长时间。以图为例，图中三条消息分别发送他的，他们的发送顺序为消息依发送后等待消息依发送结果的同步响应，等响应接收到之后再进行消息二的发送。在消息二的同步响应被接收之后，再进行消息三的同步发送。第二方式是可靠的异步发送。可靠的异步发送是指发送方发出数据后，不用等待消息队列的发送器处理结果，就可以接着发送下一个数据报的通讯方式，这种方式需要用户实现消息发送结果的回调接口。在执行消息的异步发送后，消息会通过回调接口向消息的发动者返回。消息发动的处理结果以图为定。当发动者用可靠异步方式发送消息时，可以顺序的执行。消息一，发送消息二，发送消息三，发送并不用等待消息发送结果，而是在专门的回调结口，从处理三条消息的异步响应。第三种方式是单向发送，单向发送的特点是消息发送者只负责发送消息，并不等待服气的回应，且不用设置回调函数，这就意味着发送者并不需要处理消息的发送结果，因此这种方式耗时最短，一般在微秒。但是这种方式的问题是，一旦消息发动失败，发送者并不能获得通知，所以只适合于发送日志等对发送成功率要求不高的场景。下面这张表是三种发送方式的一个对比：

如同上一页讲到的同步发送方式的特点是发送速度快，有反馈结果数据不丢失，可用于业务消息编程模式简单，但是一次发送的消息数量较少。而异步发送模式发送速度比同步方式快，有反馈结果数据不丢失。可用于业务方式有消息，但是编程模型复杂，适合于短时间内需要发送大量消息。单向发送模式发送速度最快，无法馈结果，数据可能丢失，适合日志，把数据量大，但不不严格保证送达的数据。还有一点要注意的是，从顺序消息只支持同步方式进行发送。

 

八、RocketMQ 集群消费模式

 

 

讲完了消息的发送模式，我们再来看一下消息的消费模式。一般来讲，MQ中消息的消费采用集群消费模式，在这种模式下，消费集群除了需要设置消息队列所在的，还需要设置对应的过程中的一条线。消息除了包含TOPIC属性，还包含TAG属性。消费集群可以通过选择是否接受中的全部消息，或是只接受具有某些的消息，这两者都是业务上用来归类的标识，他们的区别在于属于一级分类，而好处于一级分类下面的二级子分类。举例来说，在电商处理中，物流消费集群只需要关注Topic中物流相关的消息，而日志集群就需要关注全部的消息，在这种情况下，在创建物流集群，就需要设置物流相关的以过滤器发信息，以便接收全部消息。在我们了解了和的区别之后，就可以进行集群的创建了。在这里要注意的是，同一个消费集群中的消费实力都需要设置相同的和这种集群才可以正常地接受消息。集群创建成功后，消息队列就会让一定的负载均衡算法将Topic中符合它的过滤条件的消息发送给集群中的不同实力。在集群消费模式中，每一个消息只会发给集群中的一个实例进行处理，这样做是避免多个实力共同处理消息的情况发生。同时，在这种情况下，消息的消费进度保存在消息队列，服务端可靠性高，不会发生消息丢失的情况，是最常用的消息。处理业务消息，是最常用的业务消息处理模式。

 

九、RocketMQ 广播消费模式

 

另一种消息消费模式是广播消息消费模式，在广播消费模式下，消费集群的创建和集群消费模式并没有太大的区别，但是，在消息的接收上却有很大的不同，广播消费模式下，所有符合过滤条件的消息，都会被推给所有注册过的客户端，保证消息至少被每台机器消费一次，这种模式下，每条消息都会被大量的客户端重复处理，占用大量的系统资源。要注意的是，相比于集群消费模式，广播消费模式还有如下的特点，

首先，广播消费模式不支持数据消息，也不支持消费信息，在消费消息的消费进度，在消息实力客户端中保存，因此出现消息重复的概率大于集群消费处理模式。同时，由于服务端不维护消费进度，所以也不支持消息堆积查询、消息堆积报警，关系查询很高级功能。另外，广播消费模式不会重复投递消费失败的消息，因此消息丢失的概率也大于集群消费模式。基于以上特点，广播消费模式一般用于消费集群中消费实力的配置升级等。

系统维护工作不建议在业务消息中使用。

十、RocketMQ 消息重试

 

 

在消息队列MQ中，为了保证消息可靠逃地以及实现事物调用中的最终一致性，设计了一个非常重要的功能，城市的机制基本上无序流程进行的。在无序消息中，所有的消息产生者发送消息，首先都会可进行持久和保存，然后再推给消息消费者进行处理。如果消息消费者处理失败，可以向消息队列返回错误状态。消息队列收到错误状态后，并不会将该条消息置为一如，而是会在固定的时间进行。

上边的表是消息城市的时间间隔。一般来讲，消息城市最多城市16次，每一次的城市间隔从十秒到两个小时逐次增加。如果进行了16次，仍然还没有正确的出路，才会将该条消息一入死信队列，由用户手动处理。通过这种机制就标保证的消息处理的丢失。即使是消息处理过程中发生了错误，用户正在有机会对该条消息进行重述处理。其中要注意的是，广播消息的消息处理记录留在消息处理的消费，因此不能提供消息。

 

十一、RocketMQ 多协议接入

刚才讲到的是无序消息处理的城市机制。而在顺序消息处理模式下，由于要保证消息的严格排序，因此，当一条消息消费失败时，消息队列会一秒时间间隔不断从事该条消息，直到该条消息被消费为止。

 

 

因此，使用数学消息是务必保证因为能够及时的监控并处理消费失败的情况，以避免因为一条消息的消费失败而导致了消息推积。Mq本身提供了多种接入协议，为消息生产者和消息消费者提供调用接口，其中包括TOPIC协议，http协议和mqtt协议。其中，mqtt协议由于其使用场景和技术方案同tcp协议和http协议差别较大。因此，阿里云现在已经将它作为一个独立的产品进行推广。Mq的TCP接入协议是时间最久，公能最完善的接入协议，现在支持扎瓦到C++三种语言。Tcp协议的接入稳定性和吞吐率也是所有接入协议中最高的。另一种接入方式是http协议，http协议支持使用风格的http请求来完成消息的收发。因此，http协议介入都接入语言，并没有要求，只要支持http请求即可访问消息队列。同时，在阿里云上的mq中http协议还支持全部地域的公网介入，适合不同地域之间应用的互联互通，而tcp接入协议，这这是公网环境下的对外公网介入。但是，现阶段下http接入协议支持的功能相对于tcp接入协议还有受益，还有一定程度的受限，而消息发送的成功率和吞吐量也不如http接入方式。以上就是两种接入协各自技术特点和比较，希望同学们在使用的时候，根据自己的具体情况来选择最合适的接入方式。

 

十二、RocketMQ 消息轨迹-快速定位问题

 

阿里云上的消息队列mq相比较于开源社区版本，提供了另一个非常实用的功能就是消息轨迹。查询消息轨迹是指一条消息从生产者发送到消息队列，再从消息队列推送到消息消费者进行处理的整个流程中，各相关节点的时间状态等数据的汇总信息通过各阶段信息的汇总，形成消息传递的完整电路信息，通过消息轨迹，可以为生产环境中的问题排查提供强有力的数据支持。如果开发者根据业务日志中的信息或业务流程判断某条消息一直没有收到，这时候就可以使用消息轨迹工具来查询具体情况。

当我们需要使用消息轨迹进行查询的时候。首先我们要收集怀疑消息的相关信息，例如 key topic以及大概的发送时间范围，然后再控制台中。根据已有的消息建立查询任务，通过收集到的消息信息查询符合条件的消息。如果找到了相关消息，则控制台会显示相关消息的权电路信息。如果消息尚未消费，则可以查询该套配卡是否有消息堆积的情况。如果消息已消费，则问题很可能出在消息消费端的业务流程中。