关于中间件:消息模型主题和队列有什么区别

4次阅读

共计 1958 个字符，预计需要花费 5 分钟才能阅读完成。

能够看到，技术圈的风向始终在变，大数据、云的热度曾经在缓缓消退，当初当红的是 AI 和 IoT。这些炽热的概念，它最终要从论文和 PPT 落地，变成真正能解决问题的零碎，否则就是一个海市蜃楼。那不变的是什么？(一些题外话的感触)

最后的音讯队列，就是一个严格意义上的队列

消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分音讯

如果须要将一份音讯数据分发给多个消费者，要求每个消费者都能收到全量的音讯，例如，对于一份订单数据，风控系统、剖析零碎、领取零碎等都须要接管音讯。这个时候，单个队列就满足不了需要，一个可行的解决形式是，为每个消费者创立一个独自的队列，让 生产者发送多份 (不好的做法).

为了解决这个问题，演化出了另外一种音讯模型：“公布 – 订阅模型（Publish-Subscribe Pattern）”。

在公布 – 订阅模型中，音讯的发送方称为发布者（Publisher），音讯的接管方称为订阅者（Subscriber），服务端寄存音讯的容器称为主题（Topic）。发布者将音讯发送到主题中，订阅者在接管音讯之前须要先“订阅主题”。“订阅”在这里既是一个动作，同时还能够认为是主题在生产时的一个逻辑正本，每份订阅中，订阅者都能够接管到主题的所有音讯。

古代的音讯队列产品应用的音讯模型大多是这种公布 – 订阅模型

它是多数仍然保持应用队列模型的产品之一.

在 RabbitMQ 中，Exchange 位于生产者和队列之间，生产者并不关怀将音讯发送给哪个队列，而是将音讯发送给 Exchange，由 Exchange 上配置的策略来决定将音讯投递到哪些队列中。

同一份音讯如果须要被多个消费者来生产，须要配置 Exchange 将音讯发送到多个队列，每个队列中都寄存一份残缺的音讯数据，能够为一个消费者提供生产服务。

这也能够变相地实现新公布 – 订阅模型中，“一份音讯数据能够被多个订阅者来屡次生产”这样的性能。

RocketMQ 应用的音讯模型是规范的公布 – 订阅模型

确认机制很好地保障了消息传递过程中的可靠性，然而，引入这个机制在生产端带来了一个不小的问题。为了确保音讯的有序性，在某一条音讯被胜利生产之前，下一条音讯是不能被生产的，否则就会呈现音讯空洞，违反了有序性这个准则。

也就是说，每个主题在任意时刻，至少只能有一个消费者实例在进行生产，那就没法通过程度扩大消费者的数量来晋升生产端总体的生产性能。为了解决这个问题，RocketMQ 在主题上面减少了队列的概念。

每个主题蕴含多个队列，通过多个队列来实现多实例并行生产和生产
RocketMQ 只在队列上保障音讯的有序性，主题层面是无奈保障音讯的严格程序的 (同一队列有序, 队列之间无序)

RocketMQ 中，订阅者的概念是通过生产组（Consumer Group）来体现的。每个生产组都生产主题中一份残缺的音讯，不同生产组之间生产进度彼此不受影响，也就是说，一条音讯被 Consumer Group1 生产过，也会再给 Consumer Group2 生产。

生产组中蕴含多个消费者，同一个组内的消费者是竞争生产的关系，每个消费者负责生产组内的一部分音讯。如果一条音讯被消费者 Consumer1 生产了，那同组的其余消费者就不会再收到这条音讯。

在 Topic 的生产过程中，因为音讯须要被不同的组进行屡次生产，所以生产完的音讯并不会立刻被删除，这就须要 RocketMQ 为每个生产组在每个队列上保护一个生产地位（Consumer Offset），这个地位之前的音讯都被生产过，之后的音讯都没有被生产过，每胜利生产一条音讯，生产地位就加一。这个生产地位是十分重要的概念，咱们在应用音讯队列的时候，丢音讯的起因大多是因为生产地位处理不当导致的。

Kafka 的音讯模型和 RocketMQ 是齐全一样的.

惟一的区别是，在 Kafka 中，队列这个概念的名称不一样，Kafka 中对应的名称是分区（Partition）

主题: 公布 - 订阅
队列: 先进先出

业务模型不等于就是实现层面的模型。比如说 MySQL 和 Hbase 同样是反对 SQL 的数据库，它们的业务模型中，存放数据的单元都是“表”，然而在实现层面，没有哪个数据库是以二维表的形式去存储数据的，MySQL 应用 B+ 树来存储数据，而 HBase 应用的是 KV 的构造来存储。同样，像 Kafka 和 RocketMQ 的业务模型根本是一样的，并不是说他们的实现就是一样的，实际上这两个音讯队列的实现是齐全不同的。