[MQ]消息队列的概览

目录

前言：

1. rocketMQ对比kafka？RocketMQ怎么做到低延迟？

2. 主题和队列有什么区别？

3. 例外的消息模型-RabbitMQ(依然再用队列的思想)

4. RocketMQ的消息模型

5. kafka模型

6. 总结

---

前言：

好的架构不是设计出来的，而是演进出来的。

这个话很重要，也很有启发。

业务最适合的是最好的架构。

1. rocketMQ对比kafka？RocketMQ怎么做到低延迟？

Kafka中到处都是“批量和异步”设计，它更关注的是整体的吞吐量，而RocketMQ的设计选择更多的是尽量及时处理请求。
比如发消息，同样是用户调用了send()方法，RockMQ它会直接把这个消息发出去，而Kafka会把这个消息放到本地缓存里面，然后择机异步批量发送。
所以，RocketMQ它的时延更小一些，而Kafka的吞吐量更高。

2. 主题和队列有什么区别？

在维基百科中，队列的定义是这样的：

队列是先进先出（FIFO, First-In-First-Out）的线性表（Linear List）。在具体应用中通常用链表或者数组来实现。队列只允许在后端（称为 rear）进行插入操作，在前端（称为 front）进行删除操作。

出队严格有序，没有读的操作，读就是出队，从队列中删除。

早期的消息队列就是按照这种数据结构设计的。

如果这样设计，那么生产者会按照顺序塞到队列里面，而消息也只能呗其中一个消费者收到。

但是如果想让所有的消费者都能收到全量的消息，总不能每一个都创建一个队列吧？

但是一个消息数据被复制到多个队列浪费了资源，而且，违背了消息队列解耦的设计初衷。

所以出现了 发布订阅模型

---------------------------------------------------------------------------------

综上，发布者发布主题，可以有多个订阅者订阅这个主题。然后订阅者可以接收到消息。

消息的发送方称为发布者（Publisher）

消息的接收方称为订阅者（Subscriber）

服务端存放消息的容器称为主题（Topic）

这两种模型区别就是，生产者就是发布者，消费者就是订阅者，队列就是主题，并没有本质的区别。它们最大的区别其实就是，一份消息数据能不能被消费多次的问题。

这就是生产者与消费者 与 发布订阅模式的区别。

发布 - 订阅模型在功能层面上是可以兼容队列模型的。

现在大部分的消息队列都是发布订阅模式。

3. 例外的消息模型-RabbitMQ(依然再用队列的思想)

RabbitMQ还在用队列模型。怎么解决多个消费者的问题吗？

因为RabbitMQ有着自己独有的Exchange模块。

因为生产者直接把消息发送给exchange模块，然后呢 exchange模块来决定消息投递到那些队列中。

由Exchange上面配置的策略来决定将消息投递到那些队列里面。

同一份消息如果需要被多个消费者来消费，需要配置 Exchange 将消息发送到多个队列，每个队列中都存放一份完整的消息数据，可以为一个消费者提供消费服务。这也可以变相地实现新发布 - 订阅模型中，“一份消息数据可以被多个订阅者来多次消费”这样的功能。

还是通过队列实现，有着多个副本相当于，但是聪明的一点在于有一个Exchange模块，大概~

官网相关部分：https://www.rabbitmq.com/tutorials/tutorial-three-python.html

4. RocketMQ的消息模型

几乎所有的消息队列产品都使用一种非常朴素的“请求 - 确认”机制，确保消息不会在传递过程中由于网络或服务器故障丢失。

在生产端，生产者先将消息发送给服务端，也就是 Broker，服务端在收到消息并将消息写入主题或者队列中后，会给生产者发送确认的响应。

如果生产者没有收到服务端的确认或者收到失败的响应，则会重新发送消息；(重试机制)

在消费端，消费者在收到消息并完成自己的消费业务逻辑（比如，将数据保存到数据库中）后，也会给服务端发送消费成功的确认，服务端只有收到消费确认后，才认为一条消息被成功消费，否则它会给消费者重新发送这条消息，直到收到对应的消费成功确认。(消费者也必须需要给生产者一个明确的确认消息)

但是！！！为了确保消息的有序性，在某一条消息被成功消费之前，下一条消息是不能被消费的，否则就会出现消息空洞，违背了有序性这个原则。

为了解决这个问题，RocketMQ 在主题下面增加了队列的概念。

每个主题包含多个队列，通过多个队列来实现多实例并行生产和消费。需要注意的是，RocketMQ 只在队列上保证消息的有序性，主题层面是无法保证消息的严格顺序的。

RocketMQ 中，订阅者的概念是通过消费组（Consumer Group）来体现的。

也就是说，一条消息被 Consumer Group1 消费过，也会再给 Consumer Group2 消费。

消费组中包含多个消费者，同一个组内的消费者是竞争消费的关系，每个消费者负责消费组内的一部分消息。如果一条消息被消费者 Consumer1 消费了，那同组的其他消费者就不会再收到这条消息。（因为是竞争关系）

在 Topic 的消费过程中，由于消息需要被不同的组进行多次消费，所以消费完的消息并不会立即被删除，这就需要 RocketMQ 为每个消费组在每个队列上维护一个消费位置（Consumer Offset），这个位置之前的消息都被消费过，之后的消息都没有被消费过，每成功消费一条消息，消费位置就加一。(为什么存在消费位置，因为这个是记录队列消费到哪里了，每个queue的能力是不同的，所以得知道下一条要消费那个)

5. kafka模型

和rocketMQ很类似。唯一的区别是，在 Kafka 中，队列这个概念的名称不一样，Kafka 中对应的名称是“分区（Partition）”，含义和功能是没有任何区别的。

所以通过分区来进行（但是！！！为了确保消息的有序性，在某一条消息被成功消费之前，下一条消息是不能被消费的，否则就会出现消息空洞，违背了有序性这个原则。）满足这个事的分区。

6. 总结

像 Kafka 和 RocketMQ 的业务模型基本是一样的，并不是说他们的实现就是一样的，实际上这两个消息队列的实现是完全不同的。

接下来还要深入学习里面的实现和设计模式。