broker面向producer和consumer接受和发送消息向nameserver提供自己的消息是消息中间件的消息存储，转发的服务器路由注册：每个broker节点，在启动时都会遍历nameserver列表，与每个nameserver建立长链接，注册自己的信息(例如:brokerId,broker名称，broker地址，所属集群名等)，之后每隔30s发送一次心跳，NameServer接收到心跳后会更新时间戳。
broker集群
broker高可用，可以配成master/slave结构，master可写可读，slave只可以读，master将写入的数据同步给slave
一个master可以对应多个slave，但每一个slave只能对应一个mastermaster和slave的对应关系可以通过指定的brokerName，不同的brokerId来定义。borkerId为0表示master，非0表示slavemaster多机负载，可以部署多个broker
每个broker与nameserver集群中的所有节点建立长链接，定时注册topic信息到所有的nameserver
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对消息进行快速查询的功能
2、producer消息生产者，负责生产消息，producer通过MQ的负载均衡选择相应的broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。RocketMQ中的消息生产者都是以生产者组的形式出现的，生产者组时同一类生产者的集合，这类Producer发送相同topic类型的消息。通过nameserver集群中的其中一个节点(随机选择)建立长链接，获取topic下面的路由信息，包括topic下面有哪些queue，这些queue分布在哪些broker上等等向提供topic的master建立长链接，定时向master发送心跳 3、consumer
消息的消费者，通过NameServer集群获取topic路由信息，连接到对应的broker上消费信息，consumer会与master和slave都建立信息。
消费者组中的Consumer数量应该小于等于订阅Topic的queue数量，如果超出queue数量，多出的consumer将不能消费。
一个Topic类型的消息可以被多个消费者组同时消费
4、nameserver底层是Netty实现的，提供了路由管理，服务注册，服务发现的功能，是一个无状态节点
路由剔除：nameserver是服务发现者，集群中各个角色都需要定时向nameserver上报自己的状态，以便互相发现彼此，如果超时不上报的话，会把它从列表剔除。NameServer有一个定时任务，每隔10秒扫描一次broker列表，查看每一个broker的最新心跳时间戳距离当前时间是否超过120s，如果超过会判定失效，然后将其从broker列表中剔除
nameserver可以部署多个，当多个nameserver存在时，其他角色同时向他们上报信息，以保证高可用。
nameserver集群之间互不通信，没有主从的概念
nameserver是内存式存储，nameserver中的broker，topic等信息默认不会持久化
路由发现：RocketMQ采取的是pull模型，当Topic路由信息发生改变时，NameServer不会主动推送给客户端，而是客户端定时拉取最新的路由，默认30s拉取一次。
扩展：
pull模型：拉取模型，存在的问题：实时性较差 push模型：推送模型，实时性较好，是一个‘发布-订阅’模型，需要维护一个长链接, 而长链接的维护是需要资源成本的、该模型适用的场景： 1）实时性要求较高 2）client数量不多，Server数据变化频繁 Long Polling模型(Nacos Server用的是该模型)：长轮询模型,pull和push模型的整合
Producer和Consumer(简称客户端)如何选择NameServer：
客户端首先会生成一个随机数，然后和NameServer的节点数量取模，此时得到的是所要连接的节点的索引，然后进行连接。如果连接失败，会采用round-robin(轮询)策略，尝试连接其他节点
5.RocketMQ的消息标识rocketMQ中每个消息拥有唯一的一个MessageId,并且可以携带具有业务标识的key，以方便对消息的查询。不过需要注意的是：MessageId有两个：在生产者发送消息时会自动生成一个MessageId(msgId)，当消息到达broker后，broker也会自动生成一个MessageId(offsetMsgId),msgId，offsetMsgId，key都称为消息标识
msgId:由producer端生成，生成规则：
producerIp+进程id+MessageClientIDSetter类的classLoader的hashcode+当前时间+AutomicInteger自增计数器
offsetMsgId：由broker端生成，其生成规则：
brokerIp+物理分区的offset
key：由用户指定的业务相关的唯一标识