不爱学习的小妞博客

最近在本地做了一个测试发现，当producer端每分钟发送一条数据时，consumer端正常消费的情况下rocketmq-client-consumer-pull-rt指标的值却很高，本篇文章就来分析下原因。

在RocketMQ中有很多关于指标数据统计的实现，本篇文章就来总结下其实现的方式以及都统计了哪些数据。

问题描述：1.RocketMQ集群（V4.9.1）部署方式为一主一从，并且是同步刷盘同步复制2.当slave节点的文件系统readonly时，在master节点上执行benchmark下的producer直到Send TPS为0，此时以下程序再往集群中同步发送数据producer端在等待设置的超时时间（超时时间设置从秒级到分钟级）后catch RemotingTooMuchRequestException

最近身边有个朋友问出RocketMQ HA模式master节点文件系统readonly产生的一些问题，所以这里从源码角度分析下master节点文件系统readonly分别对broker端存储消息、HA主从同步以及对客户端的影响（源码版本是4.9.1，测试环境中配置的是同步刷盘同步复制）。

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录前言一、pandas是什么？二、使用步骤1.引入库2.读入数据总结前言提示：这里可以添加本文要记录的大概内容：例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。提示：以下是本篇文章正文内容，下面案例可供参考一、pandas是什么？示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。二、使用步骤1.引入库代码

文章目录前言一、消息轨迹二、消息轨迹源码分析1、producer端2、consumer端三、消息轨迹中存储的信息1.TraceContext2.TraceBean3.TraceType四、总结前言  本篇文章将会从以下方面介绍消息轨迹：什么是消息轨迹？如何启用消息轨迹？示例demo、消息轨迹的源码分析和消息轨迹中存储的信息。最后会用一张图来总结消息轨迹的工作原理。一、消息轨迹1.什么是消息轨迹？消息轨迹是用来跟踪记录消息发送、消息消费的轨迹。2.如何启用消息轨迹？broker端需要在b

文章目录前言一、延迟消息1.特点2.使用场景3.demo二、发送延迟消息三、broker端存储延迟消息四、总结1.延迟消息工作原理2.延迟消息在消费者消费重试中的应用前言本篇文章将会分析延迟消息的工作原理以及其在consumer端消息重试场景中的应用。一、延迟消息1.特点（1）与普通消息相比，延迟消息需要设置延迟级别，注意：延迟级别从1开始，如果延迟级别等于0则表示该消息不是延迟消息（2）延迟消息发送到broker后不会立刻被消费，而是需要等待特定时间后才被投递到真正的topic中（3）R

文章目录前言一、批量消息1. 批量消息特点2.使用场景3.demo示例二、批量消息发送1.generateFromList2.encode三、批量消息存储前言  本篇文章主要从以下几个方面来分析批量消息：批量消息的介绍、如何发送批量消息、批量消息在broker端时如何存储、消费者如何消费批量消息。一、批量消息1. 批量消息特点  批量消息有如下特点:   - 批量消息具有相同的topic   - 批量消息具有相同的waitStoreMsgOK属性   - 批量消息不支持延迟消息   -

文章目录前言一、Message对象二、DefaultMQProducer启动流程1.DefaultMQProducer启动流程图2.MQClientInstance启动3.producerGroup限制条件总结三、消息发送流程四、producer获取路由信息五、producer选择MessageQueue机制六、同步、异步及单向发送消息流程中的区别七、总结前言本篇文章来分析producer发送消息的流程，包括Message对象属性详解、producer启动流程、消息发送流程、producer获取路由信

文章目录前言一、元数据复制二、commitlog复制1.启动master并监听slave连接2.启动slave，建立与master连接及向master发送待拉取数据的物理偏移量3.master根据待拉取数据的物理偏移量打包数据并发给slave3.1 master读取数据3.2 master向slave写数据4.slave读取master发送的数据包5.总结三、同步复制与异步复制四、元数据复制与commitlog复制对比前言在RocketMQ主从架构中master和slave之间会进行数据同步，其中数据

目录前言一、NameServer启动流程二、NameServer通信线程模型三、Broker向NameServer注册路由四、路由信息详解五、删除路由信息前言在RocketMQ的架构中NameServer起到路由注册中心的作用，它一方面会接收Broker集群的注册信息并将其缓存下来，然后通过心跳监测机制来判断Broker是否存活；一方面Broker在向其发送注册的同时还会将Broker端的Topic及其配置信息发送给NameServer，NameServer也会缓存Topic相关信息。本节将通过Nam

目录前言一、RocketMQ线程模型1. NettyRemotingServer初始化2. NettyRemotingServer启动3. NettyRemotingServer线程模型4. NettyRemotingClient初始化5. NettyRemotingClient启动6. NettyRemotingClient线程模型二、RocketMQ如何实现同步、异步及单向调用1.同步调用2.异步调用3.单向调用前言本篇文章将从以下几方面分析RocketMQ的通信模块：RocketMQ的线程模

目录dledger集群搭建broker在启动的过程中如何触发选主流程dledger如何实现选主leader处理写请求及日志复制流程dledger commitlog与old commitlog数据格式对比dledger commitlog中如何构建consumequeue和index  RocketMQ集群部署可以分为两种方式master-slave和dledger，虽然master-slave方式提供了一定的高可用性，但是如果集群中的master节点挂了，这时需要运维人员手动进行重启或者切换操作，即不能

RocketMQ源码分析之pull模式consumerDefaultMQPullConsumerDefaultLitePullConsumer订阅方式的消费流程分配方式的消费流程重点方法分析DefaultMQPullConsumer与DefaultLitePullConsumer对比DefaultMQPullConsumerDefaultMQPullConsumer的实现及使用比较简单（已被废弃），从下面示例中可以看到消息的消费主要包含以下几点：构造DefaultMQPullConsumer对象，为

1.什么是request-reply？  RocketMQ4.6.0版本中增加了request-reply新特性，该特性允许producer在发送消息后同步或者异步等待consumer消费完消息并返回响应消息，类似rpc调用效果。2. 使用场景快速搭建服务总线，实现rpc框架调用链追踪分析跨网络区域实现系统间同步调用3.使用方法producer端  producer端调用request(final Message msg, final long timeout)方法以同步方式等待co

1. 使用demo以下demo来源于RocketMQ源码中example包producerproducer端除了在构建消息时设置tag外，使用putUserProperty方法对消息设置一些属性public class SqlFilterProducer { public static void main(String[] args) throws Exception { DefaultMQProducer producer = new DefaultMQProduc

1. Demo以下代码是RocketMQ源码中example包中的示例代码producerproducer端在发送消息时可以在构造消息时指定tagpublic class TagFilterProducer { public static void main(String[] args) throws Exception { DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique

前期准备前期需要安装的软件：JDKmavenGitIntelliJ IDEA源码环境搭建过程1.在IDEA中采用从Git中导入RocketMQ源码2.执行mvn clean install命令（时间稍微长一些，也可以执行mvn -Prelease-all -DskipTests clean install -U跳过测试），命令结果显示 BUILD SUCCESS3.在机器中找个合适的位置创建ROCKETMQ_HOME4.配置nameserver（1）IDEA中点击Edit Conf

  RocketMQ从4.3.0版本开始支持分布式事务消息，其采用了2PC的思想实现了提交事务消息，同时增加一个补偿逻辑处理二阶段超时或者失败的消息。本篇文章从发送事务消息及事务消息回查来分析事务消息实现的原理。事务消息整体流程首先先来看看在RocketMQ中事务消息的整体流程，如下图所示：1.producer发送消息到broker2.broker将消息存储并返回给producer响应3.执行producer本地事务并返回事务状态4.根据事务状态提交或者回滚事务5.对没有提交或者回滚的消息，

  RocketMQ支持局部消息顺序消费，即可以保证同一个消息队列中的消息被顺序消费，如果要实现全局顺序消费则需要将topic的消息队列设置为1。顺序消费与并发消费的流程大致是一样的，本篇文章从消息队列负载均衡、消息拉取及消息消费三方面来分析在RocketMQ中是如何实现消息的顺序消费。1.消息队列负载均衡  在消息消费中首先需要通过Rebalanceservice来确定消息队列与消费者的负载关系，当负载关系确定之后会向broker发送RequestCode.LOCK_BATCH_MQ类型请求锁定该消息

  在《RocketMQ源码分析之消息拉取流程》文章最后留下了一个问题：consumer端在接收到消息后是如何消费信息呢？本篇文章就来回答这个问题。  在RocketMQ中ConsumeMessageService是负责消息消费的，它其实是一个接口，实现该接口的是ConsumeMessageConcurrentlyService和ConsumeMessageOrderlyService，这两个服务分别对应一个消费模式，ConsumeMessageConcurrentlyService是并发消费，Consu

  在《RocketMQ源码分析之RebalanceService》中回答了消费者在第一次启动后是如何来获取消息这个问题，那么在构建PullRequest(消息拉取任务)后，消费者与broker之间是如何交互来完成消息拉取任务？本篇文章就来分析消息拉取流程。在consumer端与消息拉取流程相关的服务主要是RebalanceService和PullMessageService，RebalanceService主要负责consumer端消息队列负载均衡及构建PullRequest，PullMessageSer

rebalanceService的作用及启动   rebalanceService继承ServiceThread，其本质是一个线程，作用是每20秒就会调用一次doRebalance()方法来完成consumer负载均衡、将重新分配的MessageQueue构建PullRequest请求并将其放到PullMessageService服务中的pullRequestQueue队列中。...

在《RocketMQ源码分析之消息写入》中提到RocketMQ中引入consumequeue和index的原因，本篇文章将围绕consumequeue和index中记录了什么信息以及如何构建consumequeue和index文件来展开。首先我们先回顾下为什么要在RocketMQ中引入consumequeue和index。RocketMQ中所有topic的消息都存储在同一个文件中，这样虽然提高了消息发送及写入的性能及吞吐量，但是在RocketMQ中消息消费是基于topic消息订阅机制，这样便会给consu

rocketmq源码分析之消息写入1.RocketMQ存储文件Rocketmq存储路径为${ROCKET_HOME}/store，主要存储以下文件：commitlog消息存储目录consumequeue消息消费队列存储目录index消息索引文件存储目录checkpoint文件检查点，存储commitlog、consumequeue和index文件最后一次刷盘时间戳abort如果abort文件存储则表示broker非正常关闭，否则表示broker正常关闭。该文件是在