RocketMq是一个消息队列的常见架构，负责对消息的传递和管理，进而来保证服务的上下游具有一个相对较好的性能，因此在java的面试当中，RocketMq常常会最为一个考察要点来判断面试者对mq消息队列的熟悉程度，因此今天我们就对RocketMq消息队列进行分享和讲解，希望大家能从中学习到知识，能够有所收获。
1.RocketMq的数据结构
与kafka类似，RocketMq也是由发送信息的生产者，接受信息持久化到磁盘，以及接受消费者请求并处理的broker和类似于zoomkeepe的管理broker的轻量级注册中心NameServer和消费消息的消费者组成的。
2.RocketMq的topic
由于消息是有分类的，所以各种消息通过RocketMq的topic来进行分类，这样生产者就能将对应的消息发送到对应的topic的集群当中，而消费者只要订阅对应的topic就可以获取到对应需要的消息
但是同样的，我们知道一条消息是可以被多个消费者消费的，为了区分消费者的消费进度，于是RocketMq设置将topic下的信息以队列queue的方式来存储，因此通过queue当中的offset让对应的消费者进行保存，这样在下一次消费的时候，就可以通过消费者保存的offset来确认上一次的消费进度。
直到这里我们都会发现实际上RocketMq和kafka有许多的异同点，但事实上，RocketMq在topic当中还有一个tag属性，这是对消息的再一次精度的分类，是消息的精确度更高。
3.RocketMq的高可用
假设topic对应的所有queue都放在以台服务器上，那这个topic的性能瓶颈就由这台服务器来决定，为了解决这样的单机性能问题，topic下的queue被分为了多段，而每一段的queue只存储部分信息，而broker是集群，因此一个topic下的多个queue就可以被分散到不同的broker节点当中，这样我们单机存储的性能问题就被解决了。
不过依旧会存在一定的问题，首先就是虽然说消息被分散了出去，但RocketMq就只能保证单个queue队列中的消息是有序的，而同一个topic下的queue切片的有序性就无法保证了。
而其次就是，假设broker故障宕机了就会导致其所存储的部分queue数据就丢失了，这样的结果就是消息的完整性就相对较差了。
为了解决这个问题，RocketMq提供了一个对broker做主从的机制，每个主broker数据都会同步到其他的从broker节点当中，而当主节点宕机的情况出现，那么从节点就会转从为主，且主节点负责处理读写请求。
为了能够有效管理broker，注册中心nameserver主要是具有以下三项功能，首先是通过broker定时上报心跳来感知节点的改变，其次是掌管消息路由，让生产者组和消费者组知道具体发送和获取到哪个broker节点上，最后是负责集群的负载均衡和故障转移，提高系统的可用性。
4.RocketMq的生产消费者组
为了能够及时的将数据消费掉，因此RocketMq增加了消费者组的概念，多个消费者组成消费者组，而这些消费者组就能够并行的对消息进行消费。
不过RocketMq还设置了一个生产者组的概念，这个是kafka中并不具备的，而这个概念的产生是由于，kafka只是需求业务的高吞吐，而RocketMq是设计用来发送类似订单等关键重要事务的，因此就需要一个生产者有一个事务机制来帮助完成这些业务，所以需要broker知道所有的消费者与生产者都是谁，因此设计了一个生产者组来方便协调这些业务。
5.RocketMq的工作流程
为了保证工作流程顺利进行，RocketMq需要保证生产者要发送信息到哪个broker中，而消费者需要从那个broker中获取信息，因此RocketMq当中的broker集群会定时的向nameserver注册中心发送心跳包，这样nameserver就掌管了所有broker的topic和queue的信息。
生产者访问nameserver就能获取到路由信息，将消息发送给对应broker，而broker收到消息就会持久化到磁盘，然后同步数据给从节点。
消费者通过访问nameserver就可以获得订阅信息和路由信息，就知道去哪个broker中去拉取信息了。
今天的分享就到这里了，希望这篇博客能给你一些帮助，让你对关于RocketMq架构的问题得到进一步的提升，在面试的时候能从容面对面试官。