RocketMQ其实不怎么遵循JMS标准
NameServer用于收集其他角色的信息，里面存了许多列表，用于保存各角色的信息，Producer发送和Consumer消费信息都不直接与Broker打教导，而是先向NameServer询问具体要发往和消费的Topic在哪，回NameServer向二者返回该Topic所在的具体Broker地址，然后二者再连该Broker。
所以NameServer起了媒介的作用，其好处在于解耦，producer和consumer不用以硬编码的方式连broker，broker也可以动态地上下线。可以说NameServer就是一个注册中心，且是无状态的注册中心，无状态的NameServer指的是它本身没有属性。NameServer中保存的所有producer，consumer，broker的信息默认全部存在内存里，没有之久化机制。
NameServer cluster中所有NameServer没有主从之分，每一台NameServer都是独立的，互不通信，这就要求broker汇报时必须向所有NameServer都汇报，因为NameServer都是独立的，所以有一台宕机，与其他NameServer之间的数据就不统一了，所以NameServer集群只符合AP原则，不符合C原则。
RocketMQ的Topic和JMS中的Topic完全不同，可以说RocketMQ就没有这种Topic结构的存在。那么RocketMQ如何实现消息的广播，并且是以Queue的形式？通过consumer端以代码的形式配置，consumer.setMessageModel(MessageModel.BROADCASTING)，RocketMQ的broker里只存一种东西，就是Queue
RocketMQ中的Topic是逻辑上的存在。一个Topic包含一至多各Queue，一个Topic内的Queue如果太多，可以将这些Queue，也就是这个Topic以分片的方式存在多个broker上。所以Topic和Queue是包含的概念，若我们说消费一个Topic，指的其实是消费多个broker上同属这个Topic的所有Queue。
