RocketMQ服务器运行分析|学习笔记

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 快速学习RocketMQ服务器运行分析

开发者学堂课程【高校精品课-厦门大学 -JavaEE 平台技术RocketMQ服务器运行分析学习笔记,与课程紧密联系,让用户快速学习知识

课程地址:https://developer.aliyun.com/learning/course/80/detail/15977


RocketMQ服务器运行分析


我们首先要把这个服务器安装,要从他的 rocket mq的官网上头去下载下来,下载下来,以后你可以把它展开,展开到这个目录中间,我们现在下载的版本是4.7.1,所以大家可以看到在这个文件目录底下有个 rocket mq的4.7.1的目录,那进去以后,大家可以看到它里头分为几个目录,其中这个bin目录里头是他所有可以执行的东西,这里头其实主要的是用来开启动和关闭这个 rocket mq 的,

image.png

我们可以看到这里有分别有启动它的 name server以及 mq的 broker的命令,那也有这个关闭的,这 个mq shutdown的这个命令就是用来去关闭我们的这个 name server和这个 broker,按照顺序首先要来启动这个 name server,在启动的时候,会用到一个命令 nohup,nohup是程序始终在运行,用 nohup让后台始终运行,命令是 nohup bin/mqnameserver关闭我们的这个 name server和这个博客。

Server,在启动的时候,我们会用到unix的一个命令,叫做这个 lo hop no hope其实是说是让这个程序始终在运行,那我们想让用 no hope 这个命令,然后让他在后台始终运行。这个 ROMQ是基于 Java的,所以说你需要把 JDK 装好,然后要把

Java home 给设好,才能跑这个 rocket MQ。

如果没有 GDK的话,没有定义交完后面的话,它跑起来会出错那运行起来以后,他的这个输出的内容放到了这个 nohup.out文件里头,就这个当前的目录下,我们可以看一下,把它输出一下看一下。

image.png

这个 out文件中间,大家可以看到最后一项是这个 name server已启动起来了,他的类型是这个 Json,这样我们就把 name server启动起来了。name server它本身使用的是这个 logoBack的日志,他的日志记录在你的这个用户的这个目录的logos底下,所以我们可以用 telnet这个命令去看一下这个日志的最后几行,后几行是一个什么样的内容。所以我们用 log命令,去在我们的这个 home目录里头的logs,然后 rocket MQ的logs里头。有一个叫做 SVXRV的 logo文件,这样就可以看到在这个用那个 bug输出的这个过程中间,同样可以看到这个 name server已经启动了。

image.png

启动 broker,broker同样我们用 nohup来启动,那在bin底下有一个mq的broker的这个文件,我们这里需要指定这个他注册的 name server,所以用-n的命令去定义说它的 name server是所有的服务器的 ip和它的端口号,端口默认是九八七六,另外我们还需要去 log一个配置文件,因为我们把关于这个 broker的一些配置信息放到它的配置文件中间,配置文件在在这个 broker cn f的目录底下,我们看一下这个配置文件是什么样的内容,然后同样的我们按照后台运行,所以要加一个这个与的符号,这样就会把这 个 broker在后台给他运行起来,运行起来以后,同样在这个 no hop.out里头也能看到它的这个输出的结果,这里可以看到这个 broker已经启动了。

image.png

然后我们到 configure的目录底下去看一下这个配置文件,我们 configure的配置文件,这里头其实主要定义了这个 broker的一些这个相关的信息,其中最重要的是那个IP,那个定义的就是她的 broker的 IP地址,同样他的日志文件也在这个 home目录底下的logos是里头,所以我们的 logos里头的 rocket MQ的logo里头。然后看一下它的这个 broker.log文件。

看到最后几行,所以用 tell的命令。那这样同样也能看到这个 beoker启动,这个命令中间我们在使用的时候其实他的相关的信息都会输出在这,但是我们其实不通过这个日志文件去看它的使用情况,我们利用那个 rocket mq的 external中间的console console 那个工程去看他的这个情况,这个工程要从 github上把它下载下来,然后进行这个编译打包,那我们这个过程我我已经把它下载下来而且编译打包过了,所以我们直接到他的这个目录中间去用 java把它跑起来,这个工程我现在让他跑的这个端口号是八零八六,所以跑起来之前我们首先定义一下它的这个工程的name server 是什么,我们在有两种方式,一种是在配置文件去改,当然不做更改的话,我们就去设那个环境变量,所以我这儿采取的方式是设了一个环境变量,用这个 name serve r的address环 境变量给他设成了我的这个 name server的这个IP地址,这样,这个工程体系就会通过这个栏目 server去获得这个name server上所有注册的broker,然后去获得这些 broke的这个 topic的路由的信息,那我们把它启动起来以后,我们就可以来看一下它的这个运行的情况,我们的 logo host 里头的8086里头。

image.png

把它启动起来,那启动起来以后,大家首先看到的是它的 dashboard,它的主界面,现在因为我还没有运行这个生产者和消费者,所以说大家可以看到里头是没有消息的,Crossed 里头可以看到我们其中的那个 brokerA,就是启动的那个broker,它的IP地址和端口号,可以看到在这个整个的所有的这个 topic的路由信息,因为我之前有启动过,所以这里头是有这个 rock topic 和 old top的,把它删掉。我们在这里这个工具也可以控制它在服务器把它删掉,那他的这个消费组同样也跑过也是有的,所以我们也把它删掉,这个要选他在哪个broker上面的这个消费者,我们把消费者也可以删掉,这样的话让程序跑起来的时候,让他去见这些

topic,登记这个消费者。

这就是这个生产者,大家看到现在没有这个生产者,还有他的这个消息。那我们来跑一下这个我们的生产者和消费者的这个工程,因为我们是用 command line wrap,所以说用他的 plug in,把这个用 spring boot的 plug in把它跑起来,它就会发送出两条消息,我们发送消息的这个内容在日志上,在这个里头虽然能看到,所以大家可以看一下这个 console上头的这个消息,首先我们发的是这个 logo的这个消息,所以我们可以看到这个3D logo message 的这个消息,那我们也能看到这个3OLDK 这个消息。

image.png

然后我们能看到说他的消费者在消费到这个消息的时候,他的这个 a message的时候的这个内容,我们这里首先看到的是这个 orderpay的这个消息,他延迟了十秒发出去的,所以大家可以注意比较一下我这个 orderpay的这个消息,在发送的时候是18:38:42,他在收到的时候是在18:39:02,所以它虽然是有一些延迟,超过了这个十秒的间隔,接近20秒的时间,才收到了这个消息,而且我们可以看到它这个日志的这个部分来说,就收得更晚一些,因为应该是说这个服务器,刚才我们把这些东西都都删掉了,所以它应该是有一个延迟的时间要新建这个 topic,新建这些东西,所以看到这个 logo日子在他更晚点才会才收到,其实如果是发的更早,而且没有延时,这样其实也能看到说这个消息服务器其实是不能保证说这个消息一定会发

送就会收到的,它实际上是一个异步的过程。

所以这里可以看到就算是发延时消息的话,他也不是保证说在延时的那个点一定会收到,他一定会在延时的点以后,才会收到这个消息啊,这是我们在这个日志中间所看到的这个信息。那我们到 console的那个页面上去看一下他的这个内容是个什么样的结果。在 console的这个界面上,我们首先看一下他的这个 message,我们刚才发了两条 message,所以这里选一下我们的这个topic。

然后可以看到在 lock topic中间,我们刚才发送的这条消息,发送的收到的时间是18:38:41,这个 topic的这个内容,大家可以看到用美容节省发的啊,所以这就很方便的能看到这个 topic 的这个内容。我们看一下这个 pay的这条消息,pay 是38分51秒收到的,那同样它的内容就是一个三,然后我们再看一下它的这个生产者,我们有一个生产这个 broker a上面所定义的这个生产者,这样可以看到我们的生产者的那个机器的 IP,还有他的这个地址。那我们再来看消费者,消费者我们因为有两个消费者的 group,分别是 a group和 logo group。我们可以看一下这些消费者的详细的信息,大家可以看到它实际上被分配了在 broker a上面的四个队列,我们只有一个消费者我们默认的这个队列其实每一个地方有四个队列,那其中来说大家注意看在四个中间第二个队列里头其实有收到了一条消息,大家可以看到它的这个outside broker 和 consumer offset就是收到的消息 controlled是他已经消费到的消息,刚才我们只发了一条消息,但是有四个队列,这个队列全部关联到了我们的这个唯一的这个消费者的上面,那其中这个消息被发送到了第二个队列里头,没有第二个队里头,而且他的这个放进去的时间应该是十八点三十八分五十一秒,这是pay group,我们来看一下这个 topic的信息,log topic 的信息同样有三个队列,被送到编号为2的队列里头,看一下这个 older pay,同样有四个队列,在ID为1的里面,这是关于他的路由信息,说明在哪一个 broker上面,就是这个 topic在哪一个 broker上面?

我们再来看一下它的这个 broker的信息。Broker 的信息里头会显示这个 broker的一些概要的内容。最后我们来看这个,刚才我们看到有处理了这个四条消息,我们其实发送了两条,因为它烧掉了两条,发收到两条,消费了两条,所以说他总共处

理的消息就是四条在 brokerA上面。

image.png

这就是我们的这个用消息服务器的这样的一个例子,所以说记住他的这个启动顺序,我们首先要启动 name server,然后再把 broke注册到启动 broke,注册到name server 上头去,然后你才会启动这个生产者和消费者啊,然后生产者发送消息,消费者去处理消息。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
3月前
|
消息中间件 监控 数据挖掘
基于RabbitMQ与Apache Flink构建实时分析系统
【8月更文第28天】本文将介绍如何利用RabbitMQ作为数据源,结合Apache Flink进行实时数据分析。我们将构建一个简单的实时分析系统,该系统能够接收来自不同来源的数据,对数据进行实时处理,并将结果输出到另一个队列或存储系统中。
224 2
|
1月前
|
存储 监控 安全
服务器维护是确保服务器稳定运行、数据安全和性能优化的重要过程
【10月更文挑战第4天】服务器维护是确保服务器稳定运行、数据安全和性能优化的重要过程
124 65
|
3月前
|
传感器 网络协议 物联网
手把手教你在 Windows 环境中搭建 MQTT 服务器
手把手教你在 Windows 环境中搭建 MQTT 服务器
283 0
|
9天前
|
自然语言处理 编译器 应用服务中间件
PHP在服务器上的运行过程
PHP在服务器上的运行过程
28 7
|
1月前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
|
1月前
|
SQL 分布式计算 NoSQL
大数据-170 Elasticsearch 云服务器三节点集群搭建 测试运行
大数据-170 Elasticsearch 云服务器三节点集群搭建 测试运行
41 4
|
1月前
|
SQL 分布式计算 大数据
大数据-168 Elasticsearch 单机云服务器部署运行 详细流程
大数据-168 Elasticsearch 单机云服务器部署运行 详细流程
53 2
|
17天前
|
Ubuntu 关系型数据库 MySQL
如何选择适合CMS运行的服务器?
在数字互联网时代,企业与单位都需要搭建企业官网在互联网上展示自己的品牌和产品宣传。除去了传统建设公司开发网站外,使用CMS就成为常用的网站创建方式。而成功的网站除了选对CMS外,还需要考虑到搭建完CMS的服务器。今天的文章给大家介绍:如何选择CMS和服务器: 很多客户都不清楚是选择CMS还是先选择服务器?
|
1月前
|
前端开发 Java Shell
后端项目打包上传服务器部署运行记录
后端项目打包上传服务器部署运行记录
32 0
|
3月前
|
消息中间件 存储 数据中心
RocketMQ的长轮询(Long Polling)实现分析
文章深入分析了RocketMQ的长轮询实现机制,长轮询结合了推送(push)和拉取(pull)两种消息消费模式的优点,通过客户端和服务端的配合,确保了消息的实时性同时将主动权保留在客户端。文中首先解释了长轮询的基本概念和实现步骤,然后通过一个简单的实例模拟了长轮询的过程,最后详细介绍了RocketMQ中DefaultMQPushConsumer的长轮询实现方式,包括PullMessage服务、PullMessageProcessor服务和PullCallback回调的工作原理。
115 1