RocketMQ 消息收发全流程图解（设计师的视角分析）

🍊 Java学习：Java从入门到精通总结

🍊 深入浅出RocketMQ设计思想：深入浅出RocketMQ设计思想

🍊 绝对不一样的职场干货：大厂最佳实践经验指南


📆 最近更新：2022年5月5日

🍊 个人简介：通信工程本硕💪、Java程序员🌕。做过科研，发过专利，优秀的程序员不应该只是CRUD

🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力！

文章目录

• 消息发送模型
• • 消息发送流程
• 消费消息模型
• • 广播消息
  • "一对一"消息

消息发送模型

既然RocketMQ是消息队列，如果我们站在设计者的角度去思考的话，我一定会给它设计一个存储消息的机制：

• 为了做到先发过来的消息优先被消费，很自然的就能想到使用队列这种数据结构；
• 参考Redis的发送订阅模型，消费者通过订阅主题（Topic）下的消息实现定向投放；
• 此外，为了提高MQ的可靠性，我们还会设计一些冗余策略来保证消息不丢失。

从存储模型来看，MQ里有三个比较重要的概念：

• Broker：即Server，接受客户端的连接，实现服务
• Topic：业务上用来归类的标识，可以按照Redis的发布订阅模式里的主题来理解
• Queue：也称为Message Queue，消息队列，保存消息并将他们转发给消费者

此外，还可以从上图看出：

1. 用户发送的消息会在Broker中的Queue里记录
2. 一个Topic下的数据可能保存在多个Broker里
3. 一个Broker保存了多个Queue
4. 一个Topic下的一些Queue可能会冗余备份在多个Broker里

消息发送流程

好了，在解决完如何存储消息的问题之后，我们就要设计发送的具体流程了。如果你是设计者的话，我建议你不要一上来就陷入到具体的实现细节里了，而是应该从抽象到具体，先把总体流程画出来，再逐步完善。

按照这个思路，参考Redis的发送订阅模型，我们可以试着画一下RocketMQ消息发送的简要流程：

是不是很简单？一个消息从发送到接收的过程，其实就是发送者先把消息发到某个Topic下，之后消费者再去Topic下拿消息。

有了最简单的发送消息的流程之后，我们就可以结合之前画的存储消息的Broker，画出更详细的发送接收模型：

实际上，RocketMQ还允许消息发送者发送多个Topic的消息，同时，一个Topic也可以被多个消费者所订阅：

消息发送路由（负载均衡）：
前面的存储模型里面，我们设计了消息被存放在Broker中的Queue里，消息应该发送到哪个Queue里，以及消费者从哪个Queue里拿消息也是我们需要设计的。

针对这个问题，我们可以引入路由逻辑来进行选择，也可以理解为负载均衡：

消费消息模型

经过消息发送模型的分析、设计之后，不难发现，消费者在消费消息时，要能够支持两种模式：广播消息和一对一消息。

广播消息

所谓广播消息就是一条消息能够被多个Consumer都消费，如下图所示：

"一对一"消息

所谓一对一消息，并不是真的指一台机器对应一台机器的形式，现在更多的是一个Topic对应一个集群的关系。

比如有一个主题 Topic A，该主题有4个Queue，有一个消费组里有四个Consumer，该主题下的4个Queue就可以通过某个规则让一个消费组里的某个Consumer消费掉。

分配规则有以下四种：

1. 平均分配

注意这里的平均不是严格意义上的平均

2. 一致性哈希

根据Consumer的顺序，依次在Queue组成的环形图中分配。

3. 机房临近分配

了解过CDN的同学肯定都知道，我们部署服务器时，一般都会采用两地多活的策略，例如在杭州、北京、广州都有几房，为了提高性能，用户的请求都会被CDN路由到最近的服务器上，MQ也一样：