【RocketMq系列-01】RocketMq安装和基本概念

RocketMq系列整体栏目

一，RocketMq安装和基本概念

1，RocketMq基本安装(本地安装)

本次安装是直接安装在本地，首先先打开官网，将文件下载 https://rocketmq.apache.org/download ，这里用的版本是4.9.1的版本，下载Binary对应的zip，随后解压安装，如我这边安装在D盘目录下

随后在系统中，配置一个环境变量，变量名为 ROCKETMQ_HOME，变量值为解压目录

随后修改bin目录中的 runbroker.cmd 文件，将里面的堆内存调下一点

set "JAVA_OPT=%JAVA_OPT% -server -Xms512m -Xmx512m"

修改bin目录下的 runserver.cmd 文件，调小内部的堆内存和元空间内存的大小

set "JAVA_OPT=%JAVA_OPT% -server -Xms512m -Xmx512m -Xmn256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"

修改conf目录下的 broker.conf 文件，最后加入自动创建topic的配置

autoCreateTopicEnable=true

再运行bin目录下面的 mqnamesrv,cmd 文件，用于作为注册中心。在启动时可能会报错一些找不到jdk的问题，因为是默认安装，那个安装路径中有空格，重新换一个安装路径即可

再打开一个窗口，运行bin目录下的这个 mqbroker.cmd 文件

随后再新建一个环境变量，变量名为 NAMESRV_ADDR ，变量值为 localhost:9876

随后再开启一个窗口，通过bin目录下的 tools.cmd ，快速运行一个生产者的实例

tools.cmd org.apache.rocketmq.example.quickstart.Producer

出现以下日志之后，那么整个服务就算启动成功了。此时生产者已经往队列中投递了1000条数据

rocketmq的系统架构图如下，此时的Nameserver和broker已经成功开启了，并且也快速开始了一个生产者的测试类

随后再新开一个窗口，创建一个消费者，用于快速消费刚刚投递的一千条消息

tools.cmd org.apache.rocketmq.example.quickstart.Consumer

其消费的日志如下，最后消费者会将队列中的消息全部消费完

随后可以直接克隆一个项目https://rocketmq.apache.org/zh/download/#rocketmq-dashboard ，该项目是一个sprintboot的项目，直接运行即可，默认port端口是8080，如果是使用的5.0的版本，那么就需要下载这个文件https://gitcode.com/mirrors/apache/rocketmq-dashboard/overview?utm_source=csdn_github_accelerator , 本人这边选择的是4.9.1的版本，因此选择前者

localhost:8080/#/

可以发现集群，主题，消息等都是可以通过这个可视化界面查看到的

刚刚创建名为 TopicTest 的Topic主题，其status状态如下，主要有偏移量，队列等信息

队列的信息如下，会有具体的topic主题，broker的名字以及对应的队列id

MessageQueue [topic=TopicTest, brokerName=DESKTOP-B5OB02F, queueId=3]

2，Rocketmq的核心概念

其官网如下：https://rocketmq.apache.org/zh/docs/ ，因此本文的全部内容，主要是来自官网以及本人自己的总结

2.1，RocketMq组件的基本概念

在讲解rocketmq里面的各个名词之前，先看一张图，来了解整个架构的领域模型

消息 ：Message，指的是消息系统所传输信息的物理载体，是最小的数据传输单元。就是比如说一个对象等，是生产者和消费者所处理数据的最小单位，每条消息属于一个topic主题。在mq中，消息都需要进行持久化，因此每条message都会存储在磁盘上面。

主题 ：Topic，表示一类消息的集合，逻辑上是一个队列的集合。每个主题包含若干条消息，而每条消息只能属于一个主题。一个生产者可以同时发送多种topic的消息，而一个消费者只能对某种特定的topic消费，即一个消费者只能订阅和消费一种topic的消息

队列 ：Message Queue，队列就是存储具体物理消息的实体，一个topic主题中可以包含多个queue，每个queue队列存放的就是该topic中的消息。queue队列对于的就是kafka中partition分区，而队列先进先出可以现实消息的顺序性，并且可以直接通过偏移量来记录消息的位置和顺序

生产者：Product，就是作为构建并传输消息的服务端，将一些业务消息封装成Message，然后发送到某一Topic的的队列中，可以通过单条消息，也可以批量发送消息。生产者和主题的关系是多对多的关系，即一个生产者可以生产多个主题的数据，一个主题的数据也可以由多个生产者生产

消费者 ：Consumer，消费者就是用来处理和接收消息，将Message消息转换成业务可以理解的信息，一个消费者必须关联一个消费者组，被消费类型也由多种规模，如简单消费，push推送消息，pull拉取消息等

消费者组 ：Consumer Group， 承载多个消费行为一致的消费者的负载均衡分组 。这个分组实际上是一个逻辑的概念，就是将一个大的消费者拆分成多个小消费者， 这些消费者的消费逻辑和配置保持一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展

订阅关系 ：Subscription，订阅关系指的是消费者组和Topic主题之间的关系，以这二者作为最小粒度。消费者组和主题之间也是多对多的关系，并且通过这个订阅关系，在内部可以实现一些过滤规则、消费进度等元数据和相关配置

NameServer 就是一个简单的Topic注册中心，支持Topic和broker的动态注册和发现，负责管理消息队列和消费者组，他维护一个全局的队列列表，以及每个队列的读写权限和消息状态。Nameserver通常可以部署多个实例，各个实例之间不进行信息通讯，每个实例上面都会保存一份完整的路由，当某个节点出现宕机的情况，客户端可以通过别的路由获取信息。

Broker ：broker主要负责消息的存储、投递和查询以及保证服务高可用的保证。broker内部也可以搭建主从架构的集群。每个broker会和Nameserver建立长连接，将Topic的信息注册到NameServer里面

整个集群架构的底层实现如下：

• 首先Broker会和Nameserver保持长连接，然后将所有的Topic主题信息注册到Nameserver中；
• 其次是Product生产者也会和Nameserver建立长连接，会通过Nameserver的信息获取对应的Topic的master或者slave，这样Product也会和具体找到的Topic建立长连接，然后往队列中投递数据
• 最后是Consumer消费者也是和Nameserver建立长连接，会通过Nameserver的注册中心获取对应的Topic的master或者slave，这样Consumer也会和具体找到的Topic建立长连接，然后消费队列中的数据

2.2，RocketMq的通信方式

在分布式系统的架构下，如在微服务中，经常将一些复杂的模块拆分成多个小的子模块，那么此时多个子模块之间就需要涉及到通信问题，在模块与模块中主要有两种通信的方式：**一种是同步的RPC远程调用，一种是基于中间件代理的异步通信方式。 **

RPC远程调用可以直接通过长连接的方式进行直接的请求和响应，如建立tcp连接之后，通过发送心跳包等来保持长连接，即使是在不同系统间，也可以直接进行通信，如请求方直接发送请求到被调用方，被调用方立马给请求方一个响应，从而验证此次通是否成功。

异步消息的方式如下，就是服务于服务之间无需进行强藕合，请求方只需要通过异步的将请求给代理方，通过代理立马响应一个成功的请求即可，剩余的服务全由代理去完成，而发送方不需要对代理的事情关心，这样使自身的职责更加单一。而完成这种代理的事情，一般就是交给消息中间件去完成。

显而易见，Rocketmq是选择后者的通信方式，这样的好处有：

• 这样调用方和被调用方统一通过消息代理进行通信，更加的易于维护和管理，
• 上游服务和下游服务之间的耦合性弱，让上下游服务的职责更加的单一
• 流量削峰，通过中间件去解决业务流量大的问题，从而实现流量的缓冲

2.3，消息传输模型

在一般的消息中间件中，主要有两种消息的传输模型，分别是 点对点模式、发布订阅模式

点对点模式指的是生产端和消费端只需要通过一个队列实现，队列中的每一条消息只会被唯一的一个消费者处理。

发布订阅模式不同于点对点模式，在发布订阅模式中，需要消费端和主题进行订阅，每个订阅称为订阅组，如下面的M1、M2、M3，可以称为单个订阅组，只要消费者对这些消息进行了订阅，那么每个消费者都可以去消费队列中的消息，不像点对点，消费完就没了。

这二者通信模式之间，各有各的优势，但是Rocketmq为了更高的扩展性，采用的是发布订阅 的方式