Rocketmq是一个阿里开源的一款消息中间件。官网介绍如下：
Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance and reliability, trillion-level capacity and flexible scalability. It consists of four parts: name servers, brokers, producers and consumers. Each of them can be horizontally extended without a single Point of Failure。
该消息中间件有着低延迟、高性能、高可靠、亿级存储、弹性伸缩的特点。主要由四部分组成：name servers(服务发现和路由)、 brokers(消息存储和转发)、producers (消息生产者)、consumers(消息消费者)。
大致的架构图如下：
接下来我们分部拆解以下各个模块的作用。
NameServer Cluster
扮演路由信息存储和服务发现的角色。每个Broker启动的时候都会向集群中的所有NameServer进行注册，因此集群中每个NameServer都存储着全量路由信息。同时，每个NameServer直接是相互不通信的，处于隔离状态。所以严格意义上来说，NameServer Cluster是一个伪集群。
Broker Cluster
扮演消息储存和消息转发的角色。通过轻量级的Topic和Queue来提供消息存储，支持消息推拉模型。单个Broker节点都会和所有的NameServer保持长连接，定时同步Topic信息。
Producer Cluster
扮演消息发送的角色。支持分布式部署。消息由生产者通过各种负载均衡策略发送到Broker。发送过程延时低，并且支持快速失败。
Rocketmq提供了三种消息发送模式：
- 同步发送：发送消息后需要等broker回复才能执行接下来的流程，适用于消息比较重要的流程
- 异步发送：发送消息后的时候可以不用等待broker回复而执行接下来的流程，可以通过注册异步回调来处理后续流程。适用于对发送时间比较敏感但是消息又比较重要的业务。
- 单向发送：发送消息后不等broker回复就可以执行接下来的流程，并且无回调函数处理。适用于对消息可靠性不是很高的业务。
Consumer Cluster
扮演消费消息的角色。支持集群消费和广播消费：集群消费表示同一个集群下，订阅的topic里的一条信息只能够被消费一次；广播消费表示同一个集群下，订阅的topic里的一条消息能够被所有的消费者消费。同时，支持的消息消费模式也有两种： Pull 和 Push模式。
Pull Consumer 拉取型的消费者。消费者主动从Broker拉取需要消费的消息。
Push Consumer 推送型的消费者。Broker主动推送消息到Consumer端。实际实现是把轮询过程封装了，在启动初期会在重新负载之后发送一次拉取消息的请求，然后注册对应请求的监听。broker端收到这类请求之后先存起来，内部会有一个轮询进程看有没有新消息进来，如果有，那么从存储的请求信息中挑选对应的进行回复操作，到达cosumer之后触发对应的监听器进行消息消费。
以上就是Rocketmq现有架构几个模块的功能简单的分析。理清楚架构中各自的角色和作用有利于我们对使用Rocketmq过程中出现的问题快速定位。同时，Rocketmq源码也是按照上面几个部分切割的，有利于我们分步理解源码实现。
