一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第5天，点击查看活动详情。
消息发送模型
既然RocketMQ是消息队列，如果我们站在设计者的角度去思考的话，我一定会给它设计一个存储消息的机制：
- 为了做到先发过来的消息优先被消费，很自然的就能想到使用队列这种数据结构；
- 参考Redis的发送订阅模型，消费者通过订阅主题（Topic）下的消息实现定向投放；
- 此外，为了提高MQ的可靠性，我们还会设计一些冗余策略来保证消息不丢失。
从存储模型来看，MQ里有三个比较重要的概念：
- Broker：即Server，接受客户端的连接，实现服务
- Topic：业务上用来归类的标识，可以按照Redis的发布订阅模式里的主题来理解
- Queue：也称为Message Queue，消息队列，保存消息并将他们转发给消费者
此外，还可以从上图看出：
- 用户发送的消息会在Broker中的Queue里记录
- 一个Topic下的数据可能保存在多个Broker里
- 一个Broker保存了多个Queue
- 一个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也一样：