MQTT协议简单了解 - 发布/订阅模式

发布/订阅模式

发布/订阅模式（也称为pub / sub）提供了传统客户端-服务器体系结构的替代方法。在客户端服务器模型中，客户端直接与端点进行通信。发布/ 订阅模型将发送消息的客户端（发布者）与接收消息的客户端（订阅者）分离。发布者和订阅者从不彼此直接联系。实际上，他们甚至不知道另一个存在。它们之间的连接由第三个组件（代理）处理。代理的工作是过滤所有传入消息，并将其正确分发给订户。因此，让我们更深入地研究pub / sub的一些常规方面（我们将在稍后讨论MQTT的具体细节）。

MQTT发布/订阅架构

pub / sub的最重要方面是消息的发布者与收件人（订阅者）的分离。这种解耦具有几个方面：

• 空间解耦：发布者和订阅者不需要彼此了解（例如，无需交换IP地址和端口）。
• 时间解耦：发布者和订阅者不需要同时运行。
• 同步解耦：发布或接收期间，两个组件的操作都不需要中断。

总之，发布/订阅模型删除了消息的发布者与接收者/订阅者之间的直接通信。代理的过滤活动使控制哪个客户端/订户接收哪个消息成为可能。去耦具有三个维度：空间，时间和同步。

可扩展性

发布/订阅的伸缩性优于传统的客户端-服务器方法。这是因为代理上的操作可以高度并行化，并且可以以事件驱动的方式处理消息。消息缓存和消息的智能路由通常是提高可伸缩性的决定性因素。尽管如此，扩展到数百万个连接还是一个挑战。集群代理节点可以使用负载平衡器将负载分配到更多单独的服务器上，从而实现如此高的连接水平。（该主题超出了本文的讨论范围，我们将在另一篇文章中介绍）。

邮件过滤

显然，代理在发布/订阅过程中扮演着举足轻重的角色。但是，代理如何管理所有消息，以便每个订户仅接收感兴趣的消息？正如您将看到的，代理有几个过滤选项：

选项1：基于主题的过滤

此过滤基于每条消息的主题或主题。接收客户向代理订阅感兴趣的主题。从那时起，代理确保接收方的客户端获取发布到订阅主题的所有消息。通常，主题是具有分层结构的字符串，可以根据有限数量的表达式进行过滤。

选项2：基于内容的过滤

在基于内容的过滤中，代理根据特定的内容过滤器语言过滤邮件。接收客户端订阅他们感兴趣的消息的过滤查询。该方法的一个重要缺点是必须事先知道消息的内容，并且不能对其进行加密或轻易更改。

选项3：基于类型的过滤

当使用面向对象的语言时，基于消息（事件）的类型/类的过滤是一种常见的做法。例如，订户可以收听所有消息，这些消息的类型为Exception或任何子类型。

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

MQTT

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

• MQTT在空间上解耦发布者和订阅者。要发布或接收消息，发布者和订阅者只需要知道代理的主机名/ IP和端口即可

• MQTT按时间解耦。尽管大多数MQTT用例都几乎实时地传递消息，但是如果需要，代理可以为不在线的客户端存储消息。（必须满足两个条件来存储消息：客户端已与持久会话建立连接，并订阅了服务质量大于0的主题）。

• MQTT异步工作。因为大多数客户端库都是异步工作的，并且基于回调或类似模型，所以在等待消息或发布消息时不会阻塞任务。在某些使用情况下，同步是理想的并且是可能的。为了等待特定消息，某些库具有同步API。但是流程通常是异步的。

应该提到的另一件事是MQTT在客户端特别容易使用。大多数发布/订阅系统在代理方面具有逻辑，但是当使用客户端库时，MQTT实际上是发布/订阅的本质，这使得它成为小型且受约束的设备的轻量级协议。

MQTT使用基于主题的消息过滤。每个消息都包含一个主题（主题），代理可以使用该主题来确定预订客户端是否收到该消息。如果需要，您还可以使用MQTT代理和我们的自定义插件系统来设置基于内容的过滤。

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

与消息队列的区别

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

消息队列存储消息，直到被消耗为止。 使用消息队列时，每个传入消息都存储在队列中，直到客户端（通常称为使用者）将其接收到为止。如果没有客户端接收该消息，则该消息将停留在队列中并等待被使用。在消息队列中，任何客户端都无法处理消息，如果没有人订阅主题，就如同MQTT中的消息一样。

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

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