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左右量级，核心部分代码量应该更少，有时间会具体来看各项功能的使用方法与是实现方式。