本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer，已开源在github ，欢迎star！
前言
上节我们介绍了一个RMQ的简单入门级别的demo，我们知道了生产者生产消息到MQ，然后消费者订阅消费的过程，但是那只是很简单的讲解了一下，还有很多细节我们没有去细说，今天开始我们将一个个深入的讲解下，首先今天我们先讲讲RMQ的架构设计和结构。
RMQ的架构设计
下面我从GitHub上截取了一张RMQ的源码结构图，图中我框框出来的9大模块，基本就构成了整个RMQ的内部结构
上面9大模块的依赖层次主要如下，依赖越强的越处于底层：
下面介绍下最上层的4个模块，这4个模块中工具命令行就不讲了，用于终端操作RMQ的命令时使用的，另外3个模块在RMQ上都有相对应的服务可以启动并使用：
- 扮演着nameNode的角色，记录运行时消息相关的meta信息，以及broker和filtersrv运行信息，是可以集群部署的；
- 主要用于节点之间相互进行心跳检测，数据通信，集群高可用、一致性、容错性等核心模块；
-
集群模式：消费端设置消费模式为MessageModel.CLUSTERING，这种方式就可以达到水平扩展负载均衡消费消息
`consumer.setMessageModel(MessageModel.CLUSTERING);`
-
广播模式：消费端设置消费模式MessageModel.BROADCASTING这种模式下，就是相当于生产者端发送消息到RMQ，多个消费者端可以同时获得消息消息，顾名思义广播模式
`consumer.setMessageModel(MessageModel.BROADCASTING);`
扮演着nameNode的角色，记录运行时消息相关的meta信息，以及broker和filtersrv运行信息，是可以集群部署的；
rocketmq-broker：数据存储的核心，这里真正存储的MQ服务器，我们的消息存储、接收、拉取、推送操作都是在broker上进行的；
rocketmq-filtersrv：消息过滤，RMQ使用一个独立的模块对数据进行过滤，主要是通过自己编写一个过滤规则的代码，编译之后，放到filtersrv模块下，然后启动filter服务之后，消费者进行消费时，指定订阅的主题topic的时候就可指定一个过滤类，加载这个过滤类执行这个过滤规则，但是这样做其实是不太安全的，相当于我们把我们的业务逻辑直接暴露在了RMQ服务器上；
RocketMQ基本设计
消费模式
RocketMQ不遵循JMS规范，有一套自定义的机制，它不存在点对点和发布订阅模式的区别，简单的说，RMQ都是使用订阅主题的方式去发送和接收消息的，支持的消费模型有下面2种：
广播模式：消费端设置消费模式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共享；
消息存储结构如下所示：
原文始发于微信公众号（Justin的后端书架）：
