RocketMQ是阿里巴巴捐献给Apache基金会的消息队列实现。从阿里云在其消息产品对比中给出的性能特性指标来看还不错,当然至于这个指标是否可信,可能还要实际测试过才好说。

架构

RocketMQ Architecture提供了RocketMQ的架构构成,

Architecture

RocketMQ由如下几部分构成,

  • Name Server
  • Broker
  • Producer
  • Consumer

Name Server

RocketMQ没有引入第三方服务依赖,消息队列内部的服务发现以及配置更新等,都借由Name Server来完成。从功能上来说,Name Server相当于一个轻量级简化版的Zookeeper,或者说提供了类似ZK的功能。

Name Server的定位是维护RocketMQ全局相关配置,提供消息路由信息,除此之外并不包含过多复杂逻辑。因为其相对轻量级,一般一组Name Server集群可以服务多组Broker集群。

Name Server Cluster是多个Name Server实例的统称,Name Server之间并无关联,互相也不同步信息。多个Name Server的存在是为了提供高可用服务,不同实例之间的数据信息同步则实际是在数据写入的时候保证的。一份配置或消息路由信息会写入所有Name Server实例中。

Broker

RocketMQ的核心逻辑是Broker。Broker是实际用于手法消息的功能单元。从RocketMQ使用者的角度来看,生产者通过接口将消息投递到Broker,消费者从Broker获取消息进行消费。RocketMQ提供了推拉结合的方式用于获取消息。

Producer

Producer为消息生产者,实际为需要RocketMQ服务的上层系统。

Consumer

Consumer为消息消费者,实际为需要RocketMQ服务的上层系统。

概念名词

在深入了解RocketMQ之前,对一些关键概念名词需要先有一个简单的认识,Core Concept上提供了一些名词解释。

Producer

Producer为消息生产者,负责创建消息发送给Broker。RocketMQ默认提供了DefaultMQProducer、TransactionMQProducer用于发送消息。

Producer Group

Producer Group是一组Producer的名称。通常来说一个业务系统可能会奉陪一个Producer Group。Producer Group后续可以用于消息发送相关的各项管理监控功能。

Consumer

Consumer是消息消费者,用于从消息队列获取消息。

Consumer Group

Consumer Group是一组Consumer的名称。相同Group下的Consumer需要有同样的订阅关系,否则消息投递的时候可能会出现一些难以排查的问题。Consumer Group同样用于分配给不同的业务系统。通过管理工具可以控制Group的消费范围。

PullConsumer

拉取型Consumer,获取消息的方式为调用Consumer接口手动从Broker获取消息,手动更新消费位点。PullConsumer使用起来相对麻烦些,但需要细粒度控制消息从何时何处开始消费的地方可以考虑使用PullConsumer。

RocketMQ默认提供了DefaultMQPullConsumer实现。

PushConsumer

推送型Consumer,从使用者的角度来看,其提供的接口像是Broker推送消息过来进行消费。其内部也还是通过定期拉取方式从Broker获取消息。

RocketMQ默认提供了DefaultMQPushConsumer实现。

Topic

一个消息都会从属与某个Topic,可以理解成消息数据的以及类别,Producer/Consumer的消息发送/消费都是基于Topic进行处理的。

Message

RocketMQ中的消息。Message必须设置Topic以及消息体,除此之外还可以配置一些自定义属性。只要不超过预定义的消息大小,自定义属性可以任意添加。

Tag

Message可以设置Tag,Tag是系统预定义的属性。Message设置了Tag之后,在消费的时候可以根据Tag进行过滤。RocketMQ提供了几种过滤方式。可以认为Tag是Message的二级类别。

Message Model

消息投递存在两种不同类别,

Clustering

Clustering模型下,一个Topic的每一条消息只会被投递到某一个Consumer上进行消费,也就是说一个Topic的消息可能上一条消息在机器A上消费,下一条消息在机器B上消费。

Broadcasting

Broadcasting模式下,一个Topic的每一条消息会被投递到每一个Consumer上进行消费。意味着Consumer在处理消息的时候需要幂等。如果后续加上消费统计数据监控的话,这种情况下消息消费的数量就会随Consumer数量而上涨。

Message Order

RocketMQ提供了不同的顺序性能力

Concurrently

默认的消息是无序消息,因此Consumer在进行消费的时候使用Concurrently模式可以有效的提升消费的吞吐量。

Orderly

当使用顺序消息之后,Consumer需要使用Orderly消费,否则顺序也是无法保证的。

代码结构

从Apache下载RocketMQ 4.2.0代码,或是从GitHub获取当前的代码,可以看到RocketMQ代码构成为下列模块,

模块功能
broker负责实现Broker核心逻辑
client提供了给应用层使用的Producer/Consumer实现
common一些通用协议或辅助代码实现
filter提供了消息过滤所需的实现
filtersrv独立的消息过滤服务实现
logappender日志处理相关实现
namesrvNameServer的代码实现
openmessagingOMS协议相关处理
remotingMQ各进程之间的网络处理部分,基于Netty实现
srvutil少量服务进程辅助类
store消息持久化等核心逻辑实现
toolsMQ提供的tools实现

所有Java代码总共在10w左右量级,核心部分代码量应该更少,有时间会具体来看各项功能的使用方法与是实现方式。

参考