2.1、Rocket四大部分
RocketMQ主要有四大核心组成部分：NameServer、Broker、Producer以及Consumer四部分。
2.1.1、NameServer （核心部分）
Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
NameServer 是整个 RocketMQ 的“大脑” ，它是 RocketMQ 的服务注册中心，所以 RocketMQ 需要先启动 NameServer 再启动 Rocket 中的 Broker。
2.1.1.1、NameServer路由注册
NameServer通常来说也是以集群的形式来进行部署。但是NameServer是无状态的，也就是说NameServer的集群中各个部分是无差异的，各个节点之间不进行相互通信。
那么集群中各个节点是如何进行同步的呢？
在Borker节点启动之后，它会对NameServer列表进行轮训，与每一个NameServer节点建立连接，发起注册请求，而在NameServer内部也维护着一个Borker列表，用来动态存储Borker的信息。
这样做的优点
NameServer集群搭建很简单！
这样做的缺点
对于Borker必须明确指出所有NameServer地址，否者未指出的将不会进行注册！因此NameServer不能随便扩容！
2.1.1.2、NameServer路由剔除
如果Borker关机、宕机或网络抖动原因，NameServer没有收到Borker的心跳，NameServer就可能会将其从Borker列表中进行剔除！
NameServer中有一个定时任务，会每隔十秒扫描一次Borker列表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120s，如果超过则会剔除该borker。
2.1.1.3、NameServer路由发现
RocketMq默认使用的是Pull模型。当Topic信息发生变化时，NameServer不会主动推送给客户端，而客户端定时拉取主题最新的路由。默认客户端会每隔30s去拉取一次。
Push模式：推送模型。 实时性比较好，是一个“发布-订阅”模型，需要维护一个长连接。而长链接会需要消耗大量资源。Pull模型：拉取模型。存在的问题是 实时性比较差！
Long Polling模型：长轮询模型。其是对Push 和 Pull 的整合，充分利用了两种模型的优势，屏蔽了她们的劣势。
长链接：一般用于 实时性要求很高的场景 或者 Client不多，Server数据变化比较频繁的场景
2.1.1.4、NameServer客户端选择策略
这里所指的客户端是指 Producer 和 Consumer
客户端在配置时必须要写上一个NameServer集群的地址，那么客户端到底连接的是哪个NameServer的节点呢？客户端首先会首选一个随机数，然后再与NameServer的节点数取模，此时得到的就是他连接的节点的索引，然后就回去连接对应节点。如果说该节点出现异常无法连接，那么就会采用round-robin策略，逐个去连接其他的节点。
首先采用的是随机策略，连接失败之后采用的是轮询策略。
2.1.2、Broker （消息存储中心）
消息服务器（Broker）充当着消息中转角色，负责消息存储、转发。
消息服务器（Broker）是消息存储中心，主要作用是接收来自 Producer 的消息并存储，Consumer 从这里取得消息。它还存储与消息相关的元数据，包括用户组、消费进度偏移量、队列信息等。从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型，Master 既可以写又可以读，Slave不可以写只可以读。
2.1.2.1、模块构成
Remoting Moudle:整个Broker的实体，负责处理来自clients端的请求。而Borker实体则由以下模块构成。
Client Manager:客户端管理器。负责接受、解析客户端（Producter/Consumer）请求，管理客户端。例如，维护Consumer的Topic订阅信息。
Store Service：存储服务。提供方便简单的API接口，处理消息存储到物理硬盘和消息查询功能。
HA Service：高可用服务，提供 Master Broker 和 Slave Borker 之间的数据同步功能。
Index Service：索引服务。根据特定的Message Key，对投递到Borker的消息进行索引，同时也提供了快速查询的方式。
2.1.3、Producer（生产者/发布者）
也称为消息发布者，负责生产并发送消息至 Topic。
生产者向brokers发送由业务应用程序系统生成的消息。RocketMQ提供了发送：同步、异步和单向（one-way）的多种范例。
2.1.4、Consumer（消费者/订阅者）
也称为消息订阅者，负责从 Topic 接收并消费消息。
消费者从brokers那里拉取信息并将其输入应用程序。
