官网给的架构图如下。
有一些基本概念我们需要了解。
NameServer Cluster
相当于一个轻量级的注册中心，Broker 会将自己注册上去，生产者和消费者能够从这个注册中心获取 Broker 的信息。
Broker Cluster
通过轻量级的TOPIC和QUEUE机制来实现消息存储，支持推拉模型。P.S. broker 的中文有经纪人、安排、协商的意思。
这里有两个非常重要的概念：
Topic
官方定义如下
Topic是生产者在发送消息和消费者在拉取消息的类别。Topic与生产者和消费者之间的关系非常松散。具体来说，一个Topic可能有0个，一个或多个生产者向它发送消息；相反，一个生产者可以发送不同类型Topic的消息。类似的，消费者组可以订阅一个或多个主题，只要该组的实例保持其订阅一致即可
Tag
官方定义如下
标签，换句话的意思就是子主题，为用户提供了额外的灵活性。有了标签，来自同一业务模块的具有不同目的的消息可以具有相同的主题和不同的标记。标签有助于保持代码的清晰和连贯，同时标签也方便RocketMQ提供的查询功能。
我的理解是 Topic 就相当于图书馆中的一个大的目录，比如计算机学科这个目录，而 Tag 就相当于里面的小类别，比如计算机学科-操作系统这个类别。举个例子，图书馆购买图书之后，会将图书按照大分类-小分类的方式进行分类，如果学生A 对 计算机学科-操作系统这个模块的图书感兴趣，就订阅这个 Topic-Tag 下消息，每天去图书馆逛一逛，看看有没有上新。
Producer Cluster
生产者集群，消息的产出方。
Consumer Cluster
消费者集群，消息的消费方。在实际应用场景中，消费者通常以消费者组的形式出现，因为消费者一般有多个，分组能够更好地管理消费者。
RocketMQ 消息队列的整个流程大致如下所示：
1. 生产者先从本地的 Broker 列表缓存获取一个 broker ，如果不存在，就去注册中心 NameServer 上查找，查找到后往这个 Broker 发送消息
2. Broker 接受到消息后，进行一系列的检查，然后将消息写入 commitLog 中。commitLog 相当于一个日志文本，所有的消息都会往里面。它有自己固定的数据格式，所有消息的写入都必须按照规定的格式写入。commitLog 默认的文件大小是1G，超出后会另起一个文件。存入commitLog之后，就会进行刷盘。
3. 后台有个进程ReputMessageService一直查看 commitLog 的偏移量，如果偏移量发生改变，就会将消息的长度，id，起始位置等等传入给consumerQueue。
4. 当消费者发现有消息可以消费的时候就会先去 consumeQueue 中读取信息，根据consumeQueue中的信息推算出新消息在 commitLog 中的位置，然后再去 commitLog 中读取信息。
其实看完这些概念发现 RocketMQ Kafka 这两个消息中间件的架构都非常相似： 一个注册中心 + 消息队列 + 生产者 + 消费者 。 猜想它们可能在细节实现上存在差异。