首先，造成这个问题的 BUG RocketMQ 官方已经在 3月16号 的这个提交中修复了，这里只是探讨一下在修复之前造成问题的具体细节，更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥？》 ，这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作，对理解本次要讲解的 BUG 有一定的帮助。
其中讲到了：
重复消费自不必说，你 ClientID 都相同了。本篇着重聊聊为什么会消息堆积。
可能我们对 RocketMQ 的消费者认知乍一想很简单，就是一个拿来消费消息的客户端而已，你只需要指定对应的 Topic 和 ConsumerGroup，剩下的就是只需要：
就完事了。
当然，可能在实际业务场景下，确实是这样。但是如果我们不清楚 Consumer 启动之后到底会做些什么，底层的实现的一些细节，在面对复杂业务场景时，排查起来就会如同大海捞针般迷茫。
继续阅读对于 ArrayList 来说，我们平常用的最多的方法应该就是 add 和 remove 了，本文就主要通过这两个基础的方法入手，通过源码来看看 ArrayList 的底层原理。
这个应该是平常用的最多的方法了，其用法如下。
接下来我们就来看看 add 方法的底层源码。
ensureCapacityInternal 作用为：保证在不停的往 ArrayList 插入数据时，数组不会越界，并且实现自动扩容。
在之前的文章中，已经把 Broker、Producer 和 Conusmer 的部分源码和核心的机制介绍的差不多了，但是其实 RocketMQ 中还有一个比较关键但是我们平时很容易忽略的组件——NameServer。
在日常的使用中，我们接触的最多的还是 Producer 和 Consumer，而 NameServer 没有直接跟我们有交互。就像 Kafka 集群背后用于其集群元数据管理的 Zookeeper 集群一样，NameServer 也在背后支撑着 RocketMQ 正常工作。
NameServer 你可以简单的把它理解成注册中心。
Broker 启动的时候会将自己注册到 NameServer 中，注册的同时还会将 Broker 的 IP 地址、端口相关的数据，以及保存在 Broker 中的 RocketMQ 集群路由的数据一并跟随心跳发送到 NameServer。这里的路由信息是指 Topic 下的 MessageQueue 分别都在哪台 Broker 上。
而 Producer 则会从 NameServer 中获取元数据，从而将 Message 发到对应的 Broker 中去。
继续阅读Topic是一类消息的集合，是一种逻辑上的分区。为什么说是逻辑分区呢？因为最终数据是存储到Broker上的，而且为了满足高可用，采用了分布式的存储。
这和Kafka中的实现如出一辙，Kafka的Topic也是一种逻辑概念，每个Topic的数据会分成很多份，然后存储在不同的Broker上，这个「份」叫Partition。而在RocketMQ中，Topic的数据也会分布式的存储，这个「份」叫MessageQueue。
其分布可以用下图来表示。
这样一来，如果某个Broker所在的机器意外宕机，而且刚好MessageQueue中的数据还没有持久化到磁盘，那么该Topic下的这部分消息就会完全丢失。此时如果有备份的话，MQ就可以继续对外提供服务。
为什么还会出现没有持久化到磁盘的情况呢？现在的OS当中，程序写入数据到文件之后，并不会立马写入到磁盘，因为磁盘I/O是非常耗时的操作，在计算机来看是非常慢的一种操作。所以写入文件的数据会先写入到OS自己的缓存中去，然后择机异步的将Buffer中的数据刷入磁盘。
继续阅读本篇博客会从源码层面，验证在RocketMQ基础概念剖析，并分析一下Producer的底层源码中提到的结论，分别是：
Broker在启动时，会将自己注册到所有的NameServer上 Broker在启动之后，会每隔30S向NameServer发送心跳
之前的文章中，我们知道了RocketMQ中的一些核心概念，例如Broker、NameServer、Topic和Tag等等。Producer从启动到发送消息的整个过程，从源码级别分析了Producer在发送消息到Broker的时候，是如何拿到Broker的数据的，如何从多个MessageQueue中选择对应的Queue发送消息。
但是由于篇幅原因，文章开头提到的两个已知结论在上篇博客里并没没有对其进行验证，这次就从源码层面来验证一下。
由于篇幅原因，本次的源码分析只限于Producer侧的发送消息的核心逻辑，我会通过流程图、代码注释、文字讲解的方式来对源码进行解释，后续应该会专门开几篇文章来做源码分析。
这篇博客聊聊关于RocketMQ相关的东西，主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等，我在之前的文章《消息队列杂谈》已经聊过了，如果需要了解的话可以回过头去看看。
首先我们要知道，使用RocketMQ时我们经历了什么。那就是生产者发送一条消息给RocketMQ，RocketMQ拿到这条消息之后将其持久化存储起来，然后消费者去找MQ消费这条消息。
SH的全栈笔记 