RocketMQ是阿里巴巴捐献给Apache基金会的消息队列实现。从阿里云在其消息产品对比中给出的性能特性指标来看还不错,当然至于这个指标是否可信,可能还要实际测试过才好说。
架构
RocketMQ Architecture提供了RocketMQ的架构构成,
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 | 日志处理相关实现 |
namesrv | NameServer的代码实现 |
openmessaging | OMS协议相关处理 |
remoting | MQ各进程之间的网络处理部分,基于Netty实现 |
srvutil | 少量服务进程辅助类 |
store | 消息持久化等核心逻辑实现 |
tools | MQ提供的tools实现 |
所有Java代码总共在10w左右量级,核心部分代码量应该更少,有时间会具体来看各项功能的使用方法与是实现方式。