RocketMQ系列之架构浅谈

前言

上节我们介绍了一个RMQ的简单入门级别的demo，我们知道了生产者生产消息到MQ，然后消费者订阅消费的过程，但是那只是很简单的讲解了一下，还有很多细节我们没有去细说，今天开始我们将一个个深入的讲解下，首先今天我们先讲讲RMQ的架构设计和结构。

RMQ的架构设计

下面我从GitHub上截取了一张RMQ的源码结构图，图中我框框出来的9大模块，基本就构成了整个RMQ的内部结构

上面9大模块的依赖层次主要如下，依赖越强的越处于底层：

下面介绍下最上层的4个模块，这4个模块中工具命令行就不讲了，用于终端操作RMQ的命令时使用的，另外3个模块在RMQ上都有相对应的服务可以启动并使用：

rocketmq-nameserver：名称服务，可以理解成在RMQ中就是一个轻量级的ZK，但是它比zk的性能要好，可靠性更强，nameserver主要有下面2个作用：

扮演着nameNode的角色，记录运行时消息相关的meta信息，以及broker和filtersrv运行信息，是可以集群部署的；

主要用于节点之间相互进行心跳检测，数据通信，集群高可用、一致性、容错性等核心模块；

rocketmq-broker：数据存储的核心，这里真正存储的MQ服务器，我们的消息存储、接收、拉取、推送操作都是在broker上进行的；

rocketmq-filtersrv：消息过滤，RMQ使用一个独立的模块对数据进行过滤，主要是通过自己编写一个过滤规则的代码，编译之后，放到filtersrv模块下，然后启动filter服务之后，消费者进行消费时，指定订阅的主题topic的时候就可指定一个过滤类，加载这个过滤类执行这个过滤规则，但是这样做其实是不太安全的，相当于我们把我们的业务逻辑直接暴露在了RMQ服务器上；

RocketMQ基本设计

消费模式

RocketMQ不遵循JMS规范，有一套自定义的机制，它不存在点对点和发布订阅模式的区别，简单的说，RMQ都是使用订阅主题的方式去发送和接收消息的，支持的消费模型有下面2种：

集群模式：消费端设置消费模式为MessageModel.CLUSTERING，这种方式就可以达到水平扩展负载均衡消费消息

广播模式：消费端设置消费模式MessageModel.BROADCASTING这种模式下，就是相当于生产者端发送消息到RMQ，多个消费者端可以同时获得消息消息，顾名思义广播模式

GroupName

在RMQ中有一个很重要的概念，就是GroupName，无论生产者producer还是消费者consumer都必须指定一个GroupName，这个组主要用来标识生产者的唯一性，一类producer的集合，相同组下的producer通常发送同一类消息，且发送逻辑一致，消费者端也一样，消费者端在消费消息时，会平均分配给同一个组下的多个consumer消费，通过GroupName实现消费者天然的负载均衡消费。

Topic主题

每个主题表示一个逻辑上存储的概念，而在其MQ上，会有着与之对应的多个Queue队列，这个是物理存储的概念

消息存储

RocketMQ的消息存储主要由consumer queue与commit log协作完成的

consumer queue是消息的逻辑队列，用来指定消息在物理文件commit log上的位置，相当于字典的目录一样；

commit log是消息存放的物理文件，每台broker上的commitlog被本机所有的queue共享；

消息存储结构如下所示：