首先进入 RocketMQ 工程,进入/RocketMQ/bin   在该目录下有个 mqadmin 脚本 .  查看帮助:   在 mqadmin 下可以查看有哪些命令    a: 查看具体命令的使用 : sh mqadmin      b: sh mqadmin help 命令名称   例如,查看 updateTopic 的使用 sh mqadmin help updateTopic 2. 关闭nameserver和所有的broker:    进入到bin下:     sh mqshutdo

接着上一篇博客  [RocketMQ中Broker的启动源码分析(一)] 在完成准备工作后,调用start方法: public static BrokerController start(BrokerController controller) { try { controller.start(); String tip = "The broker[" + controller.getBrokerConfig().getBrokerName() + ", " + c

RocketMQ的broker用如下命令启动: nohup sh bin/mqbroker -n localhost:9876 & 使用jps查看,系统非常卡顿,broker的名字也未显示.使用top命令,发现broker的进程的内存占用率高达93%,难怪linux系统如此卡顿.解决办法:从如下路径进入rocketmq-all-4.3.2/distribution/target/apache-rocketmq/bin,找到箭头指的2个文件. 使用vim xxx.sh命令进行JVM参数配置修改:将

Broker和前面分析过的NameServer类似,需要在Pipeline责任链上通过NettyServerHandler来处理消息 [RocketMQ中NameServer的启动源码分析] 实际上就通过前面提到的SendMessageProcessor的processRequest方法处理 [RocketMQ中Broker的启动源码分析(一)] SendMessageProcessor的processRequest方法: public RemotingCommand processReques

上一篇博客的最后简单提了下CommitLog的刷盘  [RocketMQ中Broker的消息存储源码分析] (这篇博客和上一篇有很大的联系) Broker的CommitLog刷盘会启动一个线程,不停地将缓冲区的内容写入磁盘(CommitLog文件)中,主要分为异步刷盘和同步刷盘 异步刷盘又可以分为两种方式:①缓存到mappedByteBuffer -> 写入磁盘(包括同步刷盘)②缓存到writeBuffer -> 缓存到fileChannel -> 写入磁盘 (前面说过的开启内存字节缓冲

Broker的HA策略分为两部分①同步元数据②同步消息数据 同步元数据 在Slave启动时,会启动一个定时任务用来从master同步元数据 if (role == BrokerRole.SLAVE) { if (null != slaveSyncFuture) { slaveSyncFuture.cancel(false); } this.slaveSynchronize.setMasterAddr(null); slaveSyncFuture = this.scheduledExecutorS

  在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址

Broker注册 在Broker的启动函数中,添加了定时向NameServer进行注册的任务,在启动后延迟10秒向NameServer进行注册,之后定时发送心跳包,关于发送周期,首先从Broker配置的周期与60000毫秒中选出最小的那个值,然后再与10000毫秒对比,选出最大的那个,所以最长10秒钟执行一次心跳发送: public class BrokerController { public void start() throws Exception { // ... // 定时向NameS

在RocketMQ中,使用BrokerStartup作为启动类,相较于NameServer的启动,Broker作为RocketMQ的核心可复杂得多 [RocketMQ中NameServer的启动源码分析] 主函数作为其启动的入口: public static void main(String[] args) { start(createBrokerController(args)); } 首先通过createBrokerController方法生成Broker的控制器BrokerControll

本篇博客会从源码层面,验证在RocketMQ基础概念剖析,并分析一下Producer的底层源码中提到的结论,分别是: Broker在启动时,会将自己注册到所有的NameServer上 Broker在启动之后,会每隔30S向NameServer发送心跳 之前的文章中,我们知道了RocketMQ中的一些核心概念,例如Broker.NameServer.Topic和Tag等等.Producer从启动到发送消息的整个过程,从源码级别分析了Producer在发送消息到Broker的时候,是如何拿到Brok

这个load操作发生在启动broker的时候. 所以我们直接进入DefaultMessageStore的load()方法: /** * 加载数据 * * @throws IOException */ public boolean load() { boolean result = true; try { boolean lastExitOK = !this.isTempFileExist(); log.info("last shutdown {}", (lastExitOK ? &qu

解决方法: 修改broker启动脚本runbroker.sh里面的jvm参数 JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g" 改为 JAVA_OPT="${JAVA_OPT} -server -Xms128m -Xmx256m -Xmn256m" 然后重新启动broker. 另外,nameserver的启动脚本是runserver.sh,也可修改其中的jvm参数.

命令行主类:org.apache.rocketmq.tools.command.MQAdminStartup 客户端创建 topic 程序参数:updateTopic -n localhost:9876 -c DefaultCluster -t topic-zhang org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand#execute创建 topic 步骤:1. 从 nameserver 获取当前集群的 master bro

在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址 #进

概述 在上一节 RocketMQ源码详解 | Producer篇 · 其二:消息组成.发送链路 中,我们终于将消息发送出了 Producer,在短暂的 tcp 握手后,很快它就会进入目的 Broker.这次我们来自底向上的看下 Broker 端是如何接收然后分发处理消息,同时了解 RocketMQ 的 Broker 的线程模型. Netty 组件 如果你还记得上一节的内容的话那应该知道,NettyRomotingAbstract 有两个实现类,分别是 NettyRemotingClient 和

概述 在 Broker 的通用请求处理器将一个消息进行分发后,就来到了 Broker 的专门处理消息存储的业务处理器部分.本篇文章,我们将要探讨关于 RocketMQ 高效的原因之一:文件结构的良好设计与对 Page Cache 的极致"压榨". 文件系统的结构设计 在 RocketMQ 的 Broker 中,有一类叫做 CommitLog 的文件,所有在该 Broker 上的 Topic 上的消息都会顺序的写入到这个文件中. 该消息的元信息存储着消息所在的 Topic 与 Queue

使用消息中间件可以解决高并发,那是因为消息中间件可以将消息缓存到队列之中. 但是 当消息 过多的时候,几万,几十万...消息中间件也可能会宕机,所以我们可以对消息中间件进行集群,在之前的activemq中 activemq支持jms规范,点对点 发布订阅 消息模型,但是不支持分布式 (不支持集群) ,或者说集群比较麻烦 需要用到zk,activemq消息堆积能力没rocetmq消息堆积能力强  每年的双11 都是经过了验证的 但是 rocetmq 就支持分布式,集群.它的消息队列缓存的消息 比a

消息队列的流派 什么是 MQ Message Queue(MQ),消息队列中间件.很多人都说:MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶,这个给人的直觉是——MQ 是异步的,用来解耦的,但是这个只是 MQ 的效果而不是目的.MQ 真正的目的是为了通讯,屏蔽底层复杂的通讯协议,定义了一套应用层的.更加简单的通讯协议.一个分布式系统中两个模块之间通讯要么是 HTTP,要么是自己开发的 TCP,但是这两种协议其实都是原始的协议.HTTP 协议很难实现两端通讯——模块 A 可以调用 B,

1. 收不到消息-consumerOffset.json 信息错位 这种情况一般是,手动删除了store/commitlog目录里的数据等非常规手段造成了consumerOffset.json中记录的还是原来的信息,导致consumer收不到消息. rocketmq的broker,一个消息主题对应多个队列,这些队列的消费进度会记录在consumerOffset.json文件中.所以一旦这个文件中记录的还是老的offset信息,那么既然就消费不到消息. 一个主题对应几个队列,是记录在$home/s

上一篇入门基础部分对rocketmq进行了一个基础知识的讲解说明,在正式使用前我们需要进行环境的搭建,今天就来说一说rockeketmq分布式集群环境的搭建 前言 之前已经介绍了rocketmq的入门基础,相信各位已经基本了解,今天进行一个分布式集群的搭建,其实可以通过本地源码来进行源码的使用和学习,但是作为开发维护人员还是需要去了解分布式集群的部署流程,方便后面集群的调试和测试 配置参数 注意官方给的配置文件都是默认的,最简单的版本,线上的环境需要根据自己需求来进行配置,在这里说明下其中的部分

一.RocketMQ的消息存储基本介绍 先看一张图: 1.Commit log存储消息实体.顺序写,随机读.2.Message queue存储消息的偏移量.读消息先读message queue,根据偏移量到commit log读消息本身.3.索引队列用来存储消息的索引key使用mmap方式减少内存拷贝,提高读取性能.具体实现:FileChannel.map(RandomAccessFile) CommitLog以物理文件的方式存放,每台Broker上的CommitLog被本机器所有Consume