首先，造成这个问题的BUGRocketMQ官方已经在3月16号的这个提交中修复了，这里只是探讨一下在修复之前造成问题的具体细节，更多的上下文可以参考我之前写的《RocketMQConsumer启动时都干了些啥？》，这篇文章讲解了RocketMQ的Consumer启动之后都做了哪些操作，对理解本次要讲解的BUG有一定的帮助。其中讲到了：重复消费自不必说，你ClientID都相同了。本篇着重聊聊为什么会消息堆积。文章中讲到，初始化Consumer时，会初始化Rebalance的策略。你可以大致将Rebalance策略理解为如何将一个Topic下的m个MessageQueue分配给一个Consume
首先，造成这个问题的BUGRocketMQ官方已经在3月16号的这个提交中修复了，这里只是探讨一下在修复之前造成问题的具体细节，更多的上下文可以参考我之前写的《RocketMQConsumer启动时都干了些啥？》，这篇文章讲解了RocketMQ的Consumer启动之后都做了哪些操作，对理解本次要讲解的BUG有一定的帮助。其中讲到了：重复消费自不必说，你ClientID都相同了。本篇着重聊聊为什么会消息堆积。文章中讲到，初始化Consumer时，会初始化Rebalance的策略。你可以大致将Rebalance策略理解为如何将一个Topic下的m个MessageQueue分配给一个Consume
一次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基础概念剖析&源码解析中写过了，没有相关上下文的可以先去补齐一部分
