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

RocketMq系列整体栏目

内容	链接地址
【一】RocketMq安装和基本概念	https://zhenghuisheng.blog.csdn.net/article/details/134486709

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

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

在这里插入图片描述

2，rocketmq-dashboard

在rocketmq的社区中，做了一个可视化界面rocketmq-dashboard，因此可以直接拿来用，如果是4.x版本，可以直接克隆这个地址的项目，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/#/

可以发现集群，主题，消息等都是可以通过这个可视化界面查看到的。
在这里插入图片描述
首先查看Topic的目录，内部显示的就是上面创建的默认主题 Topic Test

这个主题为TopicTest 下的topic config，默认的读写队列都是4，并且下面的perm的权限是6

依旧是在这个主题为TopicTest 对应的status状态如下，主要有偏移量，队列等信息。

最大位点表示这个队列中有多少条消息，最小位点表示在这个队列下已经消费到了哪个消息，最大位点和最小位点就是表示当前队列中还有多少条消息没有被消费。
每一个Topic里面会有多个message队列，每个队列会被分配到broker中，如果有多个broker，那么默认就是平均分配到这些broker中。如一个topic中有10条消息，两个broker，那么每个broker中默认分配5条消息。

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

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

在这里插入图片描述
在消费者 Consumer Manage中，表示的是当前主题消费者的进度，默认的消费者组是 please_rename_unique_group_name_4 ，Queue表示队列的id，brokerOffset表示代理者位点，其表示当前broker的当前队列上分配到了多少条消息，consumerOffset表示消费者位点，表示当前队列消费到了哪条消息，如果代理者位点和消费者位点的值一样，就表示当前队列的数据已经被全部消费，因此diffTotal差值是0，同时也可以表示消息没有堆积
在这里插入图片描述
整个系统的架构图如下，关于生产者、消费者、Topic、Nameserver、Queue、Message之间的关系可以直接由线图表示

3，Rocketmq的核心概念

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

3.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建立长连接，然后消费队列中的数据

3.2，RocketMq的通信方式

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

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

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

在这里插入图片描述

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

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

3.3，消息传输模型

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

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

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

在这里插入图片描述

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