RocketMQ 服务基本架构
RocketMO 架构上主要分为四部分构成:
消息生产者，负责生产消息。Produce 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
RocketMQ 中的消息生产者都是以生产者组 ( Producer Group ) 的形式出现的。生产者组是同一类生产者的集合，这类 Producer 发送相同Topic类型的消息。
消息消费者，负责消费消息。一个消息消费者会从Broker服务器中获取到消息，并对消息进行相关业务处理。
RocketMQ 中的消息消费者都是以消费者组 ( Consumer Group ) 的形式出现的。消费者组是同一类消费者的集合，这类Consumer 消费的是同一个Topic类型的消息。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。
NameServer 是一个 Broker 与 Topic 路由的注册中心，支持 Broker 的动态注册与发现
主要包括两个功能 :
接受Broker集群的注册信息并且保存下来作为路由信息的基本数据;提供心跳检测机制，检查Broker是否还存活
每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费。
路由注册
NameServer 通常也是以集群的方式部署，不过，NameServer 是无状态的，即 NameServer 集群中的各个节点间是无差异的，各节点间相互不进行信息通讯。那各节点中的数据是如何进行数据同步的呢? 在 Broker 节点启动时，轮训 NameServer 列表，与每个 NameServer 节点建立长连接，发起注册请求。在 NameServer 内部维护着一个 Broker 列表，用来动态存储 Broker 的信息。
Broker 节点为了证明自己是活着的，为了维护与 NameServer 间的长连接，会将最新的信息以心跳包的方式上报给 NameServer，每30秒发送一次心跳。心跳包中包含 BrokerId、 Broker地址、Broker 名称、Broker 所属集群名称等等。NameServe r在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。
路由剔除
由于 Broker 关机、宕机或网络抖动等原因，NameServer 没有收到 Broker 的心跳，NameServer 可能会将其从 Broker 列表中剔除。
NameServer 中有一个定时任务，每隔10秒就会扫描一次Broker表，查看每一个 Brker 的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定 Broker 失效，然后将其从 Broker 列表中剔除。
路由发现
RocketMQ 的路由发现采用的是Pull模型。当 Topic 路由信息出现变化时，NameServer 不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。
客户端 NameServer 选择策略
客户端在配置时必须要写上NameServer集群的地址，那么客户端到底连接的是哪个NameServer节点呢?
客户端首先会首先一个随机数，然后再与 NameServer 节点数量取模，此时得到的就是所要连接的节点索引，然后就会进行连接。如果连接失败，则会采用 round-robin 策略，逐个尝试着去连接其它节点。
功能介绍
Broker充当着消息中转角色负责存储消息、转发消息。Broker在RocketMO系统中负责接收并存储从生产者发送来的消息，同时为费者的拉取请求作准备。Broker同时也存储着消息相关的元数据，包括消费者组消费进度偏移offset、主题、队列等。
模块构成
下图为 Broker Server 的功能模块示意图
Remoting Module
整个Broker的实体，负责处理来自clients端的请求。而这个Broker实体则由以下模块构成。
Client Manager
客户端管理器。负责接收、解析客户端(Producer/Consumer)请求，管理客户端。例如，维护Consumer的Topic订阅信息
Store Service
存储服务。提供方便简单的API接口，处理消息存储到物理硬盘和消息查询功能。
HA Service
高可用服务，提供Master Broker和 Slave Broker之间的数据同步功能。
Index Service
索引服务。根据特定的Message key，对投递到Broker的消息进行索引服务，同时也提供根据Message Key对消息进行快速查询的功能。
综述
为了增强Broker性能与吞吐量，Broker一般都是以集群形式出现的。
各集群节点中可能存放着相同Topi的不同Oueue。如果某 Broker 节点宕机，会将每个Broker集群节点进行横向扩展，即将Broker节点再建为一个HA集群，解决单点问题。
Broker节点集群是一个主从集群，即集群中具有Master与Slave两种角色。Master负责处理读写操作请求，Slave负责对Master中的数据进行备份。当Master挂掉了，Slave则会自动切换为Master去工作。所以这个Broker集群是主备集群。一个Master可以包含多个Slave，但一个Slave只能隶属于一个Master。Master与Slave 的对应关系是通过指定相同的BrokerName、不同的Brokerld 来确定的。Brokerld为0表示Master，非0表示Slave。
每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。