一、消息队列的演进
1、初始阶段
最初的消息队列，就是一个严格意义上的队列。队列是一种数据结构，先进先出，在消息入队出队过程中，保证这些消息严格有序。早期的消息队列就是按照“队列”的数据结构设计的。
队列模型：
生产者（Producer）发消息就是入队操作，消费者（Consumer）收消息就是出队也就是删除操作，服务端存放消息的容器自然就称为“队列”。
- 如果有多个生产者往同一个队列里面发送消息，这个队列中可以消费到的消息，就是这些生产者生产的所有消息的合集。消息的顺序就是这些生产者发送消息的自然顺序。
- 如果有多个消费者接收同一个队列的消息，这些消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分消息，也就是说任何一条消息只能被其中的一个消费者收到。
2、发布 - 订阅模型阶段
如果需要将一份消息数据分发给多个消费者，要求每个消费者都能收到全量的消息，例如，对于一份订单数据，风控系统、分析系统、支付系统等都需要接收消息。
这个时候，单个队列就满足不了需求，一个可行的解决方式是，为每个消费者创建一个单独的队列，让生产者发送多份。但是同样的一份消息数据被复制到多个队列中会浪费资源，更重要的是，生产者必须知道有多少个消费者。为每个消费者单独发送一份消息，这实际上违背了消息队列“解耦”这个设计初衷。
为了解决这个问题，演化出了另外一种消息模型：发布 - 订阅模型（Publish-Subscribe Pattern）
消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。
- 发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”。
- 每份订阅中，订阅者都可以接收到主题的所有消息。
3、总结：
- 在很长的一段时间，队列模式和发布 - 订阅模式是并存的。
- 有些消息队列同时支持这两种消息模型，比如 ActiveMQ。
- 对比这两种模型，生产者就是发布者，消费者就是订阅者，队列就是主题，并没有本质的区别。它们最大的区别是：一份消息数据能不能被消费多次的问题。
- 实际上，在这种发布 - 订阅模型中，如果只有一个订阅者，那它和队列模型就基本是一样的了。也就是说，发布 - 订阅模型在功能层面上是可以兼容队列模型的。
二、RabbitMQ 的消息模型
少数依然坚持使用队列模型的产品之一。
RabbitMQ 使用 Exchange 模块解决多个消费者的问题。Exchange 位于生产者和队列之间，生产者并不关心将消息发送给哪个队列，而是将消息发送给 Exchange，由 Exchange 上配置的策略来决定将消息投递到哪些队列中。
- 同一份消息如果需要被多个消费者来消费，需要配置 Exchange 将消息发送到多个队列，每个队列中都存放一份完整的消息数据，可以为一个消费者提供消费服务。
三、RocketMQ 的消息模型
RocketMQ 使用的消息模型是标准的发布 - 订阅模型。在 RocketMQ 也有队列（Queue）这个概念。
消息队列的消费机制：
几乎所有的消息队列产品都使用一种非常朴素的“请求 - 确认”机制，确保消息不会在传递过程中由于网络或服务器故障丢失。
在生产端，生产者先将消息发送给服务端，也就是 Broker，服务端在收到消息并将消息写入主题或者队列中后，会给生产者发送确认的响应。如果生产者没有收到服务端的确认或者收到失败的响应，则会重新发送消息。
在消费端，消费者在收到消息并完成自己的消费业务逻辑（比如，将数据保存到数据库中）后，也会给服务端发送消费成功的确认，服务端只有收到消费确认后，才认为一条消息被成功消费，否则它会给消费者重新发送这条消息，直到收到对应的消费成功确认。
这个确认机制很好地保证了消息传递过程中的可靠性，但是，引入这个机制在消费端带来了一个问题：为了确保消息的有序性，在某一条消息被成功消费之前，下一条消息是不能被消费的，也就是说，每个主题在任意时刻，至多只能有一个消费者实例在进行消费，那就没法通过水平扩展消费者的数量来提升消费端总体的消费性能。
为了解决这个问题，RocketMQ 在主题下面增加了队列的概念：
- 每个主题包含多个队列，通过多个队列来实现多实例并行生产和消费。需要注意的是，RocketMQ 只在队列上保证消息的有序性，主题层面是无法保证消息的严格顺序的。
- 生产者会往所有队列发消息，但不是“同一条消息每个队列都发一次”，每条消息只会往某个队列里面发送一次。
- 一个消费组，每个队列上只能串行消费，多个队列加一起就是并行消费了，并行度就是队列数量，队列数量越多并行度越大，所以水平扩展可以提升消费性能。
- 每队列每消费组维护一个消费位置（offset），记录这个消费组在这个队列上消费到哪儿了。
- 订阅者是通过消费组（Consumer Group）来体现的。每个消费组都消费主题中一份完整的消息，不同消费组之间消费进度彼此不受影响，也就是说，一条消息被 Consumer Group1 消费过，也会再给 Consumer Group2 消费。
- 消费组中包含多个消费者，同一个组内的消费者是竞争消费的关系，每个消费者负责消费组内的一部分消息。如果一条消息被消费者 Consumer1 消费了，那同组的其他消费者就不会再收到这条消息。
- 由于消息需要被不同的组进行多次消费，所以消费完的消息并不会立即被删除，这就需要 RocketMQ 为每个消费组在每个队列上维护一个消费位置（Consumer Offset），这个位置之前的消息都被消费过，之后的消息都没有被消费过，每成功消费一条消息，消费位置就加一。我们在使用消息队列的时候，丢消息的原因大多是由于消费位置处理不当导致的。
四、Kafka 的消息模型
Kafka 的消息模型和 RocketMQ 是完全一样的，唯一的区别是，在 Kafka 中，队列这个概念的名称不一样，Kafka 中对应的名称是“分区（Partition）”，含义和功能是没有任何区别的。
五、总结
- 常用的消息队列中，RabbitMQ 采用的是队列模型，但是它一样可以实现发布 - 订阅的功能。RocketMQ 和 Kafka 采用的是发布 - 订阅模型，并且二者的消息模型是基本一致的。
原文地址：https://www.cnblogs.com/chjxbt/p/11407890.html