健身变秃，coding变强

RocketMQ中使用消息轨迹功能；源码剖析RocketMQ如何实现消息轨迹功能；AsyncTraceDispatcher、ConsumeMessageHook、SendMessageHook、TraceContext、TraceBean详解

RocketMQ使用ACL做权限控制

Kafka在Zookeeper中存储的信息有哪些？

Kafka常用命令示例？Kafka的下载与安装？Kafka Server以后台启动？

授人以渔式确定kafka与zookeeper版本的对应关系

图文详述并发消费模式和顺序消费下RocketMQ消息消费超时、消息消费出现异常时的重试机制原理、源码

RocketMQ延时消息机制原理/源码解析含ScheduleMessageService、DeliverDelayedMessageTimerTask

根据日志倒推Broker如何做到准实时通知剩余Consumer

万字图文授人以渔 源码分析思路

一、背景为什么要本地运行源码呢？前一段时间遇到一个问题，每次系统自动呼叫三方运力（美团、蜂鸟、达达之类）的时候，总是会重复呼叫两次；最后排查发现是RocketMQ Consumer消费超时，进而导致重复消费，昨天在复习RocketMQ的时候，很神奇的就深入到消费的核心逻辑里了…（这里的故事下篇文章见）。理完Broker和Consumer的源码后也得出了一些结论，但需要加点日志跑一跑源码，让结论不是盖棺而论；所以就有了今天的故事。二、下载源码源码地址：https://github.com/Saint97

一、Broker接收请求Broker作为服务端接收请求的流程如下图：接收到请求之后，我们着重看一下NettyRemotingAbstract#processRequestCommand()方法，看一下它是怎么处理客户端的请求的。public void processRequestCommand(final ChannelHandlerContext ctx, final RemotingCommand cmd) { // 根据Command的Code从processorTable中获取相应的

一、前言RocketMQ所有的心跳机制：1）Producer端：Producer与NameSrv随机建立长连接，定期从NameSrv获取topic路由信息；Producer与Broker的Master结点建立长连接，用于发送消息；此外Producer与Master维持了一个心跳。2）ConSumer端：Conumser与NamseSrv随机建立长连接，定期从NameSrv获取topic路由信息；Consumer与Broker的Master和Slave结点建立长连接，用于订阅消息；

一、前言前面我们已经介绍过了消息存储在磁盘中的表现形式：RocketMQ：消息整体存储架构（CommitLog、ConsumeQueue），现在我们来介绍一下，一个生产消息请求到Broker端后，Broker端是如何保存这条消息的。二、存储架构三、存储流程源码分析1、接收消息2、存储消息四、总结...

一、前言今天原打算写一篇关于消息在Broker端如何存储的文档，刚梳理好整体文章脉络，想到一个问题：Broker端是如何接收生产消息请求的？印象中是通过Netty接收的，由于对具体的实现比较好奇，也就有了今天的故事。二、源码分析以下所有分析相关的源码注释请见GitHub中的release-4.8.0分支：https://github.com/Saint9768/rocketmq/tree/rocketmq-all-4.8.01、RemotingServer消息生产/消费服务启动又要开始快乐的找入

一、原理以集群消费为例，集群消息在同一个消费组中只能有一个消费者可以消费到这条消息；假如最开始我们有一个叫TopicA的主体，TopicA中有8个MessageQueue；有个消费组ConsumerGroupA；在最开始的时候我们只启动一个consumer1消费者实例，即consumer1这一个消费实例将消费这8个queue，如下图：然后我们在启动一个consumer2消费者实例，其会向Broker注册；这时broker发现ConsumerGroupA中新增了一个消费者实例，其会通知consumer1

## 查看RocketMQ相关日志 {user}/logs/rocketmqlogs/.cd ~/logs/rocketmqlogs/# 查看nameServer的日志tailf namesrv.log# 启动NameServernohup sh bin/mqnamesrv -n localhost:9876 &# 启动Brokernohup sh bin/mqbroker -n localhost:9876 -c conf/broker.conf &# 进入Roc

详细报错org.apache.rocketmq.tools.command.SubCommandException: TopicListSubCommand command failed at org.apache.rocketmq.tools.command.topic.TopicListSubCommand.execute(TopicListSubCommand.java:113) at org.apache.rocketmq.tools.command.MQAdminStartup.main0(

消息存储整体架构我们先把RocketMQ github上的消息存储图荡下来瞅瞅；消息存储主要体现在三个文件中：CommitLog（真正存储消息体的地方）、ConsumeQueue（某个Topic下某个Queue的消息索引信息）、IndexFile（通过key或时间区间来查询消息的索引文件）。简版：细版：producer发送消息后，消息先保存到commitLog，再异步建立该条消息对应的topic + queue对应的ConsumerQueue索引。1、CommitLogCommitLog

一、启动源我们先看一个broker的启动脚本：nohup sh bin/mqbroker -n 100.10.100.100:9876 -c conf/broker.conf &再看mqbroker启动脚本中：sh ${ROCKETMQ_HOME}/bin/runbroker.sh org.apache.rocketmq.broker.BrokerStartup $@至此，我们可以确定最终运行的是 BrokerStartup的main 方法，并将脚本参数以args的方式传入。apac

结论RocketMQ的BrokerID必须要大于0，并且0表示Master节点、>0的任意数表示Slave节点。为什么呢？不会是if/else吧。源码Broker启动脚本：nohup sh bin/mqbroker -n 100.10.100.100:9876 -c conf/broker.conf autoCreateTopicEnable=true &在启动Broker的时候，即BrokerStartup#main()方法中会运行createBrokerController()

RocketMQ tag/sql过滤消费实现原理以及消息丢失问题

源码分析RocketMQ 的Consumer是如何从Broker拉取消息的？

背景由于RocketMQ本身没有注释，当我补充完了rocketmq-client的一部分注释之后，发现mvn install到maven仓库一直报错：Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (verify) on project rocketmq-client: Failed during checkstyle execution从报错信息上我们可以到是一个plugin：m

RocketMQ中ProcessQueue是做什么的？有什么用？

RocketMQ Consumer启动流程源码解析

一、背景今天自己在阿里云玩RocketMQ的时候，一直无法启动broker，报错为：/software/rocketmq/rocketmq-all-4.8.0-bin-release/bin/runbroker.sh: line 90: 25991 Killed $JAVA ${JAVA_OPT} $@在网上查阅资料发现：我太贫穷了，我的阿里云内存只有2G，而rocket安装包bin目录下的runserver.sh和runbroker.sh中配置的最小内存占用为4G

一、背景历尽千辛万坑、终于把RocketMQ起起来–Broker无法启动，本以为万事大吉了，直接跑起项目，结果忽如一夜春风来、野火把梨花烧尽了。一看报错信息是timeout，就差RocketMQ的超时配置，然而并没有用。那么只能使用完成的google/百度大法了。然后一看、结论就是一层窗户纸，不知道就全是坑。二、完整异常Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [

一、经典的分布式事务场景示例：假设A给B转账500块，并且它俩处于不同的微服务中。要求：A减500块、B加上500块。可能发生的情况：1）A减500（成功），B加500（成功）2）A减500（失败），B加500（失败）3）A减500（成功），B加500（失败）4）A减500（失败），B加500（成功）上述1）、2）两种情况是可以保证事务的一致性的。而3）、4）两种情况是无法保证事务的一致性的。二、RocketMQ实现分布式事务原理RocketMQ在4.3版本开始提供了分布式事务功

1、版本介绍RocketMQ4.8.0maven依赖：<dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.8.0</version></dependency><dependency> <groupId