一次RocketMQ顺序消费延迟的问题定位问题背景与现象昨晚收到了应用报警，发现线上某个业务消费消息延迟了54s多（从消息发送到MQ到被消费的间隔）：2021-06-30T23:12:46.756messageprocessingisincrediblydelayed!(Currentdelaytime:54725,incredibledelaycountin10seconds:5677)查看RocketMQ的监控，发现确实发生了比较多的消息积压：从RocketMQ-Console上面查看Topic的消费者：这个Topic，业务要求是需要有序的。所以在发送的时候，指定了业务Key，并且消费的时
一次RocketMQ顺序消费延迟的问题定位问题背景与现象昨晚收到了应用报警，发现线上某个业务消费消息延迟了54s多（从消息发送到MQ到被消费的间隔）：2021-06-30T23:12:46.756messageprocessingisincrediblydelayed!(Currentdelaytime:54725,incredibledelaycountin10seconds:5677)查看RocketMQ的监控，发现确实发生了比较多的消息积压：从RocketMQ-Console上面查看Topic的消费者：这个Topic，业务要求是需要有序的。所以在发送的时候，指定了业务Key，并且消费的时
本篇博客会从源码层面，验证在RocketMQ基础概念剖析，并分析一下Producer的底层源码中提到的结论，分别是：Broker在启动时，会将自己注册到所有的NameServer上Broker在启动之后，会每隔30S向NameServer发送心跳之前的文章中，我们知道了RocketMQ中的一些核心概念，例如Broker、NameServer、Topic和Tag等等。Producer从启动到发送消息的整个过程，从源码级别分析了Producer在发送消息到Broker的时候，是如何拿到Broker的数据的，如何从多个MessageQueue中选择对应的Queue发送消息。但是由于篇幅原因，文章开头
本篇博客会从源码层面，验证在RocketMQ基础概念剖析，并分析一下Producer的底层源码中提到的结论，分别是：Broker在启动时，会将自己注册到所有的NameServer上Broker在启动之后，会每隔30S向NameServer发送心跳之前的文章中，我们知道了RocketMQ中的一些核心概念，例如Broker、NameServer、Topic和Tag等等。Producer从启动到发送消息的整个过程，从源码级别分析了Producer在发送消息到Broker的时候，是如何拿到Broker的数据的，如何从多个MessageQueue中选择对应的Queue发送消息。但是由于篇幅原因，文章开头
可能我们对RocketMQ的消费者认知乍一想很简单，就是一个拿来消费消息的客户端而已，你只需要指定对应的Topic和ConsumerGroup，剩下的就是只需要：接收消息处理消息就完事了。当然，可能在实际业务场景下，确实是这样。但是如果我们不清楚Consumer启动之后到底会做些什么，底层的实现的一些细节，在面对复杂业务场景时，排查起来就会如同大海捞针般迷茫。相反，你如果了解其中的细节，那么在排查问题时就会有更多的上下文，就有可能会提出更多的解决方案。关于RocketMQ的一些基础概念、一些底层实现之前都已在文章RocketMQ基础概念剖析&源码解析中写过了，没有相关上下文的可以先去补齐一部分
可能我们对RocketMQ的消费者认知乍一想很简单，就是一个拿来消费消息的客户端而已，你只需要指定对应的Topic和ConsumerGroup，剩下的就是只需要：接收消息处理消息就完事了。当然，可能在实际业务场景下，确实是这样。但是如果我们不清楚Consumer启动之后到底会做些什么，底层的实现的一些细节，在面对复杂业务场景时，排查起来就会如同大海捞针般迷茫。相反，你如果了解其中的细节，那么在排查问题时就会有更多的上下文，就有可能会提出更多的解决方案。关于RocketMQ的一些基础概念、一些底层实现之前都已在文章RocketMQ基础概念剖析&源码解析中写过了，没有相关上下文的可以先去补齐一部分
由于篇幅原因，本次的源码分析只限于Producer侧的发送消息的核心逻辑，我会通过流程图、代码注释、文字讲解的方式来对源码进行解释，后续应该会专门开几篇文章来做源码分析。这篇博客聊聊关于RocketMQ相关的东西，主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等，我在之前的文章《消息队列杂谈》已经聊过了，如果需要了解的话可以回过头去看看。基础概念Broker首先我们要知道，使用RocketMQ时我们经历了什么。那就是生产者发送一条消息给Roc
由于篇幅原因，本次的源码分析只限于Producer侧的发送消息的核心逻辑，我会通过流程图、代码注释、文字讲解的方式来对源码进行解释，后续应该会专门开几篇文章来做源码分析。这篇博客聊聊关于RocketMQ相关的东西，主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等，我在之前的文章《消息队列杂谈》已经聊过了，如果需要了解的话可以回过头去看看。基础概念Broker首先我们要知道，使用RocketMQ时我们经历了什么。那就是生产者发送一条消息给Roc
TopicTopic是一类消息的集合，是一种逻辑上的分区。为什么说是逻辑分区呢？因为最终数据是存储到Broker上的，而且为了满足高可用，采用了分布式的存储。这和Kafka中的实现如出一辙，Kafka的Topic也是一种逻辑概念，每个Topic的数据会分成很多份，然后存储在不同的Broker上，这个「份」叫Partition。而在RocketMQ中，Topic的数据也会分布式的存储，这个「份」叫MessageQueue。其分布可以用下图来表示。这样一来，如果某个Broker所在的机器意外宕机，而且刚好MessageQueue中的数据还没有持久化到磁盘，那么该Topic下的这部分消息就会完全丢失
TopicTopic是一类消息的集合，是一种逻辑上的分区。为什么说是逻辑分区呢？因为最终数据是存储到Broker上的，而且为了满足高可用，采用了分布式的存储。这和Kafka中的实现如出一辙，Kafka的Topic也是一种逻辑概念，每个Topic的数据会分成很多份，然后存储在不同的Broker上，这个「份」叫Partition。而在RocketMQ中，Topic的数据也会分布式的存储，这个「份」叫MessageQueue。其分布可以用下图来表示。这样一来，如果某个Broker所在的机器意外宕机，而且刚好MessageQueue中的数据还没有持久化到磁盘，那么该Topic下的这部分消息就会完全丢失
