关于 RocketMQ ClientID 相同引发的消息堆积的问题
首先，造成这个问题的 BUG RocketMQ 官方已经在 3月16号 的这个提交中修复了，这里只是探讨一下在修复之前造成问题的具体细节，更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥？》 ，这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作，对理解本次要讲解的 BUG 有一定的帮助。
...大约 5 分钟
RocketMQ Consumer 启动时都干了些啥？
可能我们对 RocketMQ 的消费者认知乍一想很简单，就是一个拿来消费消息的客户端而已，你只需要指定对应的 Topic 和 ConsumerGroup，剩下的就是只需要：
- 接收消息
- 处理消息
就完事了。
...大约 9 分钟
NameServer 核心原理解析
在之前的文章中，已经把 Broker、Producer 和 Conusmer 的部分源码和核心的机制介绍的差不多了，但是其实 RocketMQ 中还有一个比较关键但是我们平时很容易忽略的组件——NameServer。
在日常的使用中，我们接触的最多的还是 Producer 和 Consumer，而 NameServer 没有直接跟我们有交互。就像 Kafka 集群背后用于其集群元数据管理的 Zookeeper 集群一样，NameServer 也在背后支撑着 RocketMQ 正常工作。
...大约 7 分钟
RocketMQ基础概念剖析
Topic
Topic是一类消息的集合，是一种逻辑上的分区。为什么说是逻辑分区呢？因为最终数据是存储到Broker上的，而且为了满足高可用，采用了分布式的存储。
这和Kafka中的实现如出一辙，Kafka的Topic也是一种逻辑概念，每个Topic的数据会分成很多份，然后存储在不同的Broker上，这个「份」叫Partition。而在RocketMQ中，Topic的数据也会分布式的存储，这个「份」叫MessageQueue。
...大约 21 分钟
从RocketMQ的Broker源码层面验证一下这两个点
本篇博客会从源码层面，验证在RocketMQ基础概念剖析，并分析一下Producer的底层源码中提到的结论，分别是：
- Broker在启动时，会将自己注册到所有的NameServer上
- Broker在启动之后，会每隔30S向NameServer发送心跳
...大约 9 分钟
RocketMQ基础概念剖析，并分析一下Producer的底层源码
由于篇幅原因，本次的源码分析只限于Producer侧的发送消息的核心逻辑，我会通过流程图、代码注释、文字讲解的方式来对源码进行解释，后续应该会专门开几篇文章来做源码分析。
这篇博客聊聊关于RocketMQ相关的东西，主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等，我在之前的文章《消息队列杂谈》已经聊过了，如果需要了解的话可以回过头去看看。
...大约 14 分钟
消息队列杂谈
本篇文章聊聊消息队列相关的东西，内容局限于我们为什么要用消息队列，消息队列究竟解决了什么问题，消息队列的选型。
为了更容易的理解消息队列，我们首先通过一个开发场景来切入。
不使用消息队列的场景
首先，我们假设A同学负责订单系统的开发，B、C同学负责开发积分系统、仓储系统。我们知道，在一般的购物电商平台上，我们下单完成后，积分系统会给下单的用户增加积分，然后仓储系统会按照下单时填写的信息，发出用户购买的商品。
那问题来了，积分系统、仓储系统如何感知到用户的下单操作？
你可能会说，当然是订单系统在创建完订单之后调用积分系统、仓储系统的接口了
...大约 14 分钟