发布和订阅 - MQTT 要点：第 2 部分

发布和订阅 - MQTT 要点：第 2 部分

发布/订阅模式

​ MQTT 发布/订阅模式（也称为发布/订阅）提供了传统客户端-服务器架构的替代方案。在客户端服务器模型中，客户端直接与终结点通信。发布/订阅模型将发送消息的客户端（发布者）与接收消息的客户端（订阅者）分离。发布者和订阅者从不直接联系对方。事实上，他们甚至不知道对方的存在。它们之间的连接由第三个组件（代理）处理。代理的工作是过滤所有传入的消息并将其正确分发给订阅者。因此，让我们更深入地了解发布/订阅的一些一般方面（我们将在一分钟内讨论 MQTT 的细节）。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-riV1j00b-1681714372166)(C:\Users\Administrator\Desktop\mqtt教程\图片\mqtt-publish-subscribe.svg)]

发布/订阅最重要的方面是消息发布者与接收者（订阅者）的分离。这种解耦有几个维度：

• 空间解耦：发布者和订阅者不需要相互了解（例如，不交换 IP 地址和端口）。
• 时间解耦：发布服务器和订阅服务器不需要同时运行。
• 同步解耦：在发布或接收过程中，两个组件上的操作不需要中断。

​ 总之，MQTT 发布/订阅模型消除了消息发布者和接收者/订阅者之间的直接通信。代理的过滤活动可以控制哪个客户端/订阅者接收哪个消息。解耦有三个维度：空间、时间和同步。

可扩展性

​ MQTT 发布/订阅的扩展性优于传统的客户端-服务器方法。这是因为代理上的操作可以高度并行化，并且可以以事件驱动的方式处理消息。消息缓存和消息的智能路由通常是提高可伸缩性的决定性因素。尽管如此，扩展到数百万个连接仍然是一个挑战。可以使用集群代理节点实现如此高级别的连接，以使用负载平衡器将负载分布到更多单独的服务器上。

邮件过滤

​ 很明显，MQTT 代理在发布/订阅过程中起着关键作用。但是，代理如何设法过滤所有消息，以便每个订阅者仅接收感兴趣的消息？如您所见，代理有几个过滤选项：

• 基于主题的过滤

​ 此筛选基于作为每封邮件一部分的主题或主题。接收客户端订阅代理以获取感兴趣的主题。从那时起，代理将确保接收客户端获得发布到订阅主题的所有消息。通常，主题是具有分层结构的字符串，允许基于有限数量的表达式进行筛选。

• 基于内容的筛选

​ 在基于内容的过滤中，代理根据特定的内容过滤器语言过滤消息。接收客户端订阅它们感兴趣的消息的筛选器查询。此方法的一个显着缺点是必须事先知道消息的内容，并且无法加密或轻松更改。

• 基于类型的筛选

​ 使用面向对象语言时，基于消息（事件）的类型/类进行筛选是一种常见的做法。例如，订阅者可以侦听所有消息，这些消息的类型为 Exception 或任何子类型。

​ 当然，发布/订阅并不是每个用例的答案。在使用此模型之前，需要考虑一些事项。发布者和订阅者的解耦是发布/订阅的关键，它本身也带来了一些挑战。例如，您需要事先了解已发布数据的结构。对于基于主题的筛选，发布者和订阅者都需要知道要使用哪些主题。要记住的另一件事是消息传递。发布者不能假定有人正在侦听发送的消息。在某些情况下，可能没有订阅者读取特定消息。

MQTT – 它是什么，它的主要功能是什么？

​ 现在我们已经大致探讨了发布/订阅模型，让我们专门关注 MQTT。根据您想要实现的目标，MQTT 体现了我们提到的发布/订阅的所有方面：

• MQTT 在空间上分离发布者和订阅者。要发布或接收消息，发布者和订阅者只需要知道代理的主机名/IP 和端口。
• MQTT 按时间解耦。尽管大多数 MQTT 用例都近乎实时地传递消息，但如果需要，代理可以为不在线的客户端存储消息。（存储消息必须满足两个条件：客户端已连接到持久会话并订阅了服务质量大于 0 的主题）。
• MQTT 异步工作。由于大多数客户端库都是异步工作的，并且基于回调或类似模型，因此在等待消息或发布消息时不会阻止任务。在某些用例中，同步是可取且可能的。为了等待特定消息，某些库具有同步 API。但流程通常是异步的。

​ 应该提到的另一件事是 MQTT 在客户端特别容易使用。大多数发布/订阅系统在代理端都有逻辑，但在使用客户端库时，MQTT 确实是发布/订阅的本质，这使其成为小型和受限设备的轻量级协议。

​ MQTT 使用基于主题的消息过滤。每条消息都包含一个主题（主题），代理可以使用该主题来确定订阅客户端是否收到消息。请参阅 MQTT 要点的第 5 部分以了解有关主题概念的更多信息。如果需要，您还可以使用 HiveMQ MQTT 代理和我们的自定义扩展系统设置基于内容的过滤。

​ 为了应对发布/订阅系统的挑战，MQTT 具有三个服务质量 （QoS） 级别。您可以轻松指定消息从客户端成功传递到代理或从代理传递到客户端。但是，有可能没有人订阅特定主题。如果这是一个问题，经纪人必须知道如何处理这种情况。例如，HiveMQ MQTT 代理有一个插件系统可以解决这种情况。您可以让代理采取行动，或者只是将每条消息记录到数据库中以进行历史分析。为了保持分层主题树的灵活性，非常仔细地设计主题树并为未来的用例留出空间非常重要。如果您遵循这些策略，MQTT 非常适合生产设置。

与消息队列的区别

​ 关于 MQTT 的名称以及该协议是否作为消息队列实现存在很多混淆。我们将尝试阐明该主题并解释差异。在上一篇文章中，我们提到 MQTT 指的是 IBM 的 MQ 系列产品，与“消息队列”无关。无论名称来自何处，了解 MQTT 与传统消息队列之间的区别都很有用：

​ 消息队列存储消息，直到消息被使用为止 使用消息队列时，每个传入消息都存储在队列中，直到客户端（通常称为使用者）拾取它。如果没有客户端选取消息，则消息将保留在队列中并等待被使用。在消息队列中，消息不可能不被任何客户端处理，就像在 MQTT 中没有人订阅主题一样。

​ 一条消息仅由一个客户端使用 另一个很大的区别是，在传统的消息队列中，一条消息只能由一个使用者处理。负载在队列的所有使用者之间分配。在 MQTT 中，行为恰恰相反：订阅主题的每个订阅者都会收到消息。

​ 队列已命名，必须显式创建 队列比主题严格得多。在使用队列之前，必须使用单独的命令显式创建队列。只有在命名并创建队列后，才能发布或使用消息。相比之下，MQTT 主题非常灵活，可以即时创建。

​ 如果您能想到我们忽略的任何其他差异，我们很乐意在评论中听取您的意见。

​ 在下一篇文章中，我们将更仔细地研究是什么造就了MQTT客户端和代理以及两者如何连接。