MQTT发布和订阅架构
正如OPC UA 同样也遵循OPC的Server和Client框架，那么MQTT又是什么框架呢？
MQTT Publish / Subscribe 发布订阅框架
MQTT 协议基于发布/订阅模型工作。在传统的网络通信中，客户端和服务器直接相互通信。客户端向服务器请求资源或数据，然后，服务器将处理并发回响应。但是，MQTT 使用发布/订阅模式将消息发送者（发布者）与消息接收者（订阅者）解耦。相反，作为消息代理的第三个组件将处理发布者和订阅者之间的通信。代理的工作是筛选所有来自发布者的传入消息，并将它们正确地分发给订阅者。
举个简单例子，图示Device1和Device2两个设备：
- 设备 1 发布到一个主题Topic。
- 设备 2 订阅了与设备 1 发布的相同主题。
- 所以，设备 2 收到了消息Message。
MQTT Client and Broker
MQTT 客户端和代理
正如上述提到的架构，客户端将消息发布到不同的主题，由代理接收这些消息并根据主题进行过滤。然后，代理将这些消息发送给已订阅这些不同主题的相应客户端。
任何发布/订阅协议的核心是 MQTT 代理（Broker）。根据其实现方式，一个代理可以处理数千个同时连接的 MQTT 客户。所有通信都必须由代理接收，然后进行分类，确定谁订阅了每个主题，将消息发送给已订阅的客户端。代理还保存所有持久会话，包括错过的消息和订阅。
代理的工作是筛选所有来自发布者的传入消息，并将它们正确地分发给订阅者。代理将发布者和订阅者解耦，如下所示：
- 空间解耦：发布者和订阅者不知道彼此的网络位置，也不交换 IP 地址或端口号等信息。
- 时间解耦：发布者和订阅者不会同时运行或具有网络连接。
- 同步解耦：发布者和订阅者都可以发送或接收消息，而不会互相干扰。例如，订阅者不必等待发布者发送消息。
Working of MQTT
MQTT 的工作原理
MQTT 的发布/订阅（pub/sub）通信模式旨在最大化可用带宽，是与传统客户端服务器架构直接与终端通信的一种替代方案。在 pub/sub 模式中，发布消息的客户端（发布者）和接收消息的客户端（订阅者）之间并没有直接连接。第三方——代理服务器——管理发布者和订阅者之间的关系，因为它们之间并不直接通信。
发布者和订阅者，指的是客户端是发布消息还是订阅接收消息，是 MQTT 客户端的两种功能。同一个 MQTT 客户端可以同时实现这两种功能。当客户端或设备想要向服务器或代理服务器提交数据时，就会发生发布。
“订阅”指的是这一过程的逆向操作。在 pub/sub 模式下，多个客户端可以连接到代理服务器并订阅他们感兴趣的主题。
当代理和订阅客户端失去联系时，代理会将消息存储在缓冲区中，并在代理重新上线后将消息发送给订阅者。如果发布客户端突然断开与代理的连接，代理有权中断与订阅者的通信并向其发送包含发布者指令的缓存消息。
“发布者发送消息，订阅者接收他们感兴趣的消息，代理将发布者的消息传递给订阅者。”IBM 的一篇文档这样描述发布/订阅模式。MQTT 客户端，如发布者和订阅者，只能与 MQTT 代理进行通信。任何运行 MQTT 库的设备或程序都可以成为 MQTT 客户端，从像 Arduino 这样的微控制器到托管在云端的应用服务器。
参考链接：
- /
- /
- /