参考文档：https://mqtt.org/getting-started/
MQTT是物联网（IoT）最常用的消息传输协议。MQTT是MQ遥测传输的缩写。该协议是一套规则，定义了物联网设备如何通过互联网发布和订阅数据。MQTT用于物联网和工业物联网（IIoT）设备之间的信息传递和数据交换，如嵌入式设备、传感器、工业PLC等。该协议是事件驱动的，使用发布/订阅（Pub/Sub）模式连接设备。发送方（Publisher）和接收方（Subscriber）通过主题（Topic）进行通信，彼此之间是解耦的。它们之间的连接是由MQTT代理处理的。MQTT代理过滤所有传入的消息，并将它们正确地分发给订阅者。
1、MQTT介绍
1.1、MQTT 简介
“MQTT是一个客户端服务器发布/订阅消息的传输协议。它是轻量级的、开放的、简单的，而且设计得很容易实现。这些特点使它在许多情况下都是理想的选择，包括受限制的环境，如机器对机器（M2M）和物联网（IoT）背景下的通信，其中需要较小的代码足迹和/或网络带宽是有优势的。”—— MQTT 3.1.1规范
MQTT规范的摘要很好地描述了MQTT的内容。它是一个非常轻量级的二进制协议，由于其最小的数据包开销，与HTTP等协议相比，MQTT在电线上传输数据时表现出色。该协议的另一个重要方面是，MQTT在客户端非常容易实现。易用性是MQTT发展过程中的一个关键问题，并使其成为当今资源有限的受限设备的完美选择。
1.2、一点点历史
MQTT协议是由Andy Stanford-Clark（IBM）和Arlen Nipper（Arcom，现在的Cirrus Link）于1999年发明的。他们需要一个最小电池损耗和最小带宽的协议，以便通过卫星与石油管道连接。这两位发明家为未来的协议指定了几个要求：
- 简单的实现；
- 服务质量的数据交付；
- 轻量级，带宽高；
- 数据无关紧要；
- 持续的会话感知。
这些目标仍然是MQTT的核心。然而，该协议的主要焦点已经从专有的嵌入式系统转变为开放的物联网（IoT）用例。这种焦点的转移造成了很多关于MQTT的缩写代表什么的混乱。简短的回答是，MQTT不再被认为是一个首字母缩写。MQTT只是该协议的名称。
较长的答案是，前者的缩写代表MQ遥测传输。
"MQ "指的是MQ系列，这是IBM开发的一个支持MQ遥测传输的产品。当Andy和Arlen在1999年创建他们的协议时，他们用IBM的产品来命名它。许多消息来源将MQTT错误地标记为一个消息队列协议。这根本不是事实。MQTT不是一个传统的消息队列解决方案（尽管在某些情况下有可能对消息进行排队，这一事实我们将在接下来的文章中详细讨论）。在接下来的十年里，IBM在内部使用该协议，直到他们在2010年将MQTT 3.1作为免版税版本发布。从那时起，欢迎每个人都来实现和使用该协议。
我们在2012年开始认识了MQTT，并在同年建立了第一个版本的HiveMQ。2013年，我们向公众发布了HiveMQ。随着协议规范的发布，IBM为Eclipse基金会新成立的Paho项目贡献了MQTT客户端的实现。这些事件对该协议来说绝对是一件大事，因为如果没有一个支持性的生态系统，几乎没有机会广泛采用。
1.3、OASIS标准和当前版本
在最初发布约3年后，宣布MQTT将在OASIS（一个以推进标准为目的的开放组织）的羽翼下实现标准化。AMQP、SAML和DocBook只是之前发布的OASIS标准中的几个。标准化过程花了大约1年时间。2014年10月29日，MQTT成为正式批准的OASIS标准。从3.1到3.1.1的小版本变化表明，对前一个版本的修改很少。有关这些变化的详细信息，请参见我们关于3.1.1的优势的博文。
2019年3月，OASIS批准了新的MQTT 5规范。这个新的MQTT版本为MQTT引入了部署在云平台上的物联网应用所需的新功能，以及那些需要更多的可靠性和错误处理来实现关键任务的信息传递。要了解更多关于MQTT 5的信息，请查看我们的MQTT 5精华系列博客。
我们强烈建议使用MQTT 5。
2、发布和订阅基础知识
2.1、MQTT 发布/订阅模式
MQTT发布/订阅模式（也称为pub/sub）为传统的客户端-服务器架构提供了一个替代方案。在客户端-服务器模式中，客户端直接与端点进行通信。pub/sub模式将发送消息的客户端（发布者）与接收消息的客户端（订阅者）解耦。发布者和订阅者从不直接联系对方。事实上，他们甚至不知道对方的存在。他们之间的联系由第三个组件（经纪人）处理。经纪人的工作是过滤所有传入的消息，并将它们正确地分发给订阅者。因此，让我们深入了解一下发布/订阅的一些一般方面（我们将在一分钟内谈论MQTT的具体内容）。
pub/sub最重要的方面是消息的发布者与接收者（订阅者）的解耦。这种解耦有几个方面：
- 空间解耦。发布者和订阅者不需要互相认识（例如，不交换IP地址和端口）。
- 时间解耦。发布者和用户不需要在同一时间运行。
- 同步解耦。在发布或接收期间，两个组件上的操作都不需要中断。
总之，MQTT的pub/sub模型取消了消息的发布者和接收者/订阅者之间的直接通信。代理商的过滤活动使得控制哪个客户/用户收到哪个消息成为可能。解耦有三个层面：空间、时间和同步。
2.2、可扩展性
** MQTT Pub/Sub的扩展性比传统的客户-服务器方法好**。这是因为代理上的操作可以高度并行化，消息可以以事件驱动的方式处理。消息缓存和消息的智能路由往往是提高可扩展性的决定性因素。尽管如此，扩展到数百万的连接是一个挑战。这样高的连接量可以通过集群的经纪人节点来实现，使用负载均衡器将负载分配到更多的单个服务器上。(这个话题超出了当前文章的范围，我们将在另一篇文章中介绍）。
2.3、信息过滤
很明显，MQTT代理在发布/订阅过程中起着关键的作用。但是，经纪人是如何过滤所有的消息，使每个订阅者只收到感兴趣的消息的呢？正如你将看到的，代理有几个过滤方案：
- 方案1-基于主题的过滤：这种过滤是基于作为每个消息一部分的主题或话题。接收客户端向经纪人订阅感兴趣的主题。从那时起，经纪人确保接收客户端获得所有发布在订阅主题上的消息。一般来说，主题是具有分层结构的字符串，允许根据有限的表达方式进行过滤。
- 方案2-基于内容的过滤：在基于内容的过滤中，经纪人根据特定的内容过滤语言来过滤消息。接收客户端订阅他们感兴趣的消息的过滤查询。这种方法的一个重要缺点是，消息的内容必须事先知道，而且不能加密或轻易改变。
- 方案3-基于类型的过滤：当使用面向对象的语言时，基于消息（事件）的类型/类别进行过滤是一种常见的做法。例如，一个用户可以监听所有的消息，这些消息的类型是Exception或任何子类型。
当然，发布/订阅不是每个用例的答案。在你使用这种模式之前，有几件事你需要考虑。发布者和订阅者的解耦是pub/sub的关键，它本身也带来一些挑战。例如，你需要事先了解发布的数据是如何结构化的。对于基于主题的过滤，发布者和订阅者都需要知道要使用哪些主题。另一件需要注意的事情是信息传递。发布者不能假设有人在收听所发送的消息。在某些情况下，有可能没有订阅者阅读某条消息。
2.4、MQTT 的主要特点
现在我们已经探讨了一般的发布/订阅模型，让我们具体关注一下MQTT。根据你想要实现的目标，MQTT体现了我们所提到的发布/订阅的所有方面：
- MQTT在空间上将发布者和订阅者解耦。为了发布或接收消息，发布者和订阅者只需要知道经纪商的主机名/IP和端口。
- MQTT在时间上进行解耦。尽管大多数MQTT用例都是以近乎实时的方式传递消息，但如果需要的话，经纪人可以为不在线的客户存储消息。(要存储消息必须满足两个条件：客户端已经连接了一个持久的会话，并且订阅了一个服务质量大于0的主题）。
- MQTT以异步方式工作。因为大多数客户端库都是异步工作的，并且是基于回调或类似的模型，任务在等待消息或发布消息时不会被阻塞。在某些用例中，同步化是可取的，也是可能的。为了等待某个消息，一些库有同步的API。但流程通常是异步的。
另一件应该提到的事情是，MQTT在客户端特别容易使用。大多数pub/sub系统的逻辑都在代理方，但MQTT在使用客户端库时确实是pub/sub的精髓，这使得它成为小型和受限设备的轻量级协议。
MQTT使用基于主题的消息过滤。每条消息都包含一个主题（topic），经纪人可以用它来决定订阅的客户端是否能得到该消息。请参阅MQTT要点的第5部分，了解更多关于主题的概念。如果需要，你也可以用HiveMQ MQTT代理和我们的自定义扩展系统来设置基于内容的过滤。
为了应对pub/sub系统的挑战，MQTT有三个服务质量（QoS）级别。你可以很容易地指定一个消息被成功地从客户端传递给代理，或从代理传递给客户端。然而，有可能没有人订阅这个特定的主题。如果这是一个问题，经纪人必须知道如何处理这种情况。例如，HiveMQ MQTT代理有一个插件系统，可以解决这种情况。你可以让经纪人采取行动，或者简单地将每条消息记录到数据库中进行历史分析。为了保持分层主题树的灵活性，必须非常仔细地设计主题树，并为未来的用例留下空间。如果你遵循这些策略，MQTT是生产设置的完美选择。
2.5、MQTT 与消息队列的区别
对于MQTT这个名字，以及该协议是否以消息队列的形式实现，有很多人感到困惑。我们将尝试对这个话题进行一些说明，并解释其中的区别。在上一篇文章中，我们提到MQTT指的是IBM的MQseries产品，与 "消息队列 "没有关系。不管这个名字来自哪里，了解MQTT和传统的消息队列之间的区别是非常有用的。
当你使用一个消息队列时，每个传入的消息都被储存在队列中，直到它被一个客户（通常称为消费者）取走。如果没有客户端拿起该消息，该消息仍停留在队列中，等待被消费。在消息队列中，消息不可能不被任何客户端处理，就像在MQTT中，如果没有人订阅一个主题一样。
一个消息只被一个客户消费。另一个很大的区别是，在传统的消息队列中，一个消息只能被一个消费者处理。负载是在一个队列的所有消费者之间分配的。在MQTT中，行为则完全相反：每个订阅主题的订阅者都能得到消息。
队列是命名的，必须明确创建队列 队列比主题要严格得多。在使用队列之前，必须用一个单独的命令明确地创建队列。只有在队列被命名和创建之后，才有可能发布或消费消息。相比之下，MQTT主题非常灵活，可以即时创建。