|
在机智云的整个架构里面，如上图，GAgent实现了从模块到云端的数据交互，其实GAgent里面就是用MQTT协议实现的，可见MQTT协议的重要性。从今天开始的几节内容，小编将会带大家了解物联网MQTT协议的内容。这里先介绍MQTT信息和协议背景。 MQTT介绍
MQTT是客户端服务器发布/订阅消息传输协议，它重量轻，开放，简单，设计好，易于实施，这些特性使其成为在许多情况下的理想选择，包括了受限的环境，例如在机器到机器（M2M）和物联网（IoT）环境中的通信，只需要小的代码占用和低网络带宽。
MQTT规范的摘要很好地描述了MQTT是什么，它是非常轻量级的二进制协议，相比于HTTP之类的协议，在传输数据上比较优越因为它只有最小的数据包开销。另一个重要的方面是MQTT在客户端非常容易实现，这很适合于有限资源的设备。实际上，这是MQTT发明的目标之一。 MQTT的一点点历史
MQTT于1999年由Andy Stanford-Clark（IBM）和Arlen Nipper（Arcom，现为Cirrus Link）发明，当他们的是创建一个协议，以最小的电池损耗和最小带宽连接把石油管道通过卫星进行连接。他们指定了以下目标，未来的协议应该有：
简单的实现 提供优质的服务数据传递 轻量级和带宽效率高 数据不可知 连续环节的认证
这些目标仍然是MQTT的核心，虽然重点已经从专有的嵌入式系统改为开放的物联网使用案例，另一件事是经常困惑为什么是MQTT是缩写呢？MQTT的意义是什么？这是一个漫长的故事，简短的回答是，MQTT正式没有缩写，只是MQTT，（mqtt很长的一段历史这里省略了） 标准版本和当前版本
大约3年后首次出版，据宣布，MQTT应在OASIS的标准化下进行，OASIS是一个开放组织，旨在提高标准，AMQP，SAML，DocBook只是已经发布的几个标准标准化过程大约需要1年时间，2014年10月29日，MQTT被正式批准为OASIS标准。 MQTT 3.1.1现在是该协议的最新版本。 发布/订阅模式
发布/订阅模式（pub / sub）是传统客户端 - 服务器模型的替代方案，客户端直接与端点通信。然而，Pub / Sub将正在接收消息（称为订户）的另一客户端（或更多客户端）发送特定消息（称为发布者）的客户端去耦，这意味着发布者和订阅者不了解彼此的存在，有一个第三个组件，称为代理，由它作为中转，它将过滤所有传入的消息并相应地分发给它们，所以我们来详细介绍一下刚刚提及的方面。记住，这仍然是关于pub / sub的基本部分，我们将在短短的一个时间内讨论MQTT细节。
如上所述，pub / sub的主要方面是发布者和接收者的解耦，可以在更多维度上进行区分 总之，发布/订阅解除消息的发布者和接收者，通过过滤消息，只有某些客户端可能接收到某些消息，解耦有三个维度：空间，时间，同步。 可扩展性
Pub / Sub还提供比传统的客户端 - 服务器方法更大的可扩展性，这是因为代理上的操作可以高度并行化并处理事件驱动，消息缓存和消息的智能路由通常也是提高可扩展性的决定性因素，但是，扩展发布/订阅数百万的连接绝对是一个挑战，这可以使用集群代理节点实现，以便通过负载平衡器将负载分配到更多个体服务器上（这个问题，我会在后面详细讲解） 消息过滤
那么有趣的是，代理如何筛选所有的消息的？为什么每个订阅者只收到它感兴趣的消息？ 过滤是基于主题的，这是每个消息的一部分，接收客户端订阅与该代理商感兴趣的主题，并从中获取所有基于订阅主题的消息，主题通常具有层次结构的字符串，允许基于有限数量的表达式进行过滤。 基于内容的过滤正如名称所说的的那样，当代理根据特定内容过滤器语言过滤消息时，因此，客户端订阅过滤他们感兴趣的消息的进行查询，这样做的一大缺点是，消息的内容必须事先知道，不能轻易加密或更改。 当使用面向对象语言时，通常的做法是根据消息的类型/类进行过滤 ，在这种情况下，订阅者可以监听这种类型所有消息。
当然，发布/订阅不是一个新技术，在使用它之前有些事情要考虑。发布商和订阅者的解耦pub / sub的关键，这里也带来了一些要求，您必须事先知道已发布数据的结构，在基于主题的过滤的情况下，发布者和订阅者都需要了解正确的主题，另一方面是传递消息，发布者不能假设有人正在收听他发送的消息，因此，任何用户都不会读取消息。 MQTT中的发布和订阅
现在我们已经学到了很多关于发布/订阅的内容，但是在具体的MQTT中呢?MQTT体现了所有提到的方面，这取决于你想要实现的内容。MQTT解除了发布者和订阅者的空间上的耦合，所以他们只需要知道主机名/ ip和端口的代理才能发布/订阅消息。它也能在时间上分离，但这往往只是一个倒退的行为，因为主要是实时发送消息。当然，代理能够为不在线的客户端存储消息（这需要两个条件：客户端连接一次，会话持续，并且已经订阅了服务质量大于0的主题）。
MQTT也能够解耦同步，因为大多数客户端库都是异步工作的，并且基于回调或类似模型。因此，在等待消息或发布消息时不会阻止其他任务。但是在某些使用情况下，同步是可取的，也是可能的，因此，某些库具有同步API以及等待某个消息。但通常流程是异步的。应该提到的另一件事是MQTT在客户端特别容易使用，大多数pub / sub系统在代理方面具有最大的逻辑，但是MQTT在使用客户端库实际上是pub / sub的本质，并且使其成为小型而且受限设备的轻量级协议。
采用基于消息的主题过滤MQTT，每个消息都包含一个主题，如果订阅客户端将收到消息，则代理用于查找，有关主题的更多详细信息，请参见MQTT 要点的第5部分。还可以使用HiveMQ MQTT代理及其自定义插件系统进行基于内容的过滤。为了处理一般的pub/sub 系统的挑战，MQTT具有服务质量（QoS）级别，很容易指定消息从客户端成功传递到代理或从代理到客户端，但仍然有机会没有人订阅特定的主题。
如果这是一个问题，这取决于代理服务器如何处理这种情况。例如，HiveMQ MQTT代理有一个插件系统，它能够识别这种情况并采取行动或只是将每条消息记录到数据库中进行历史分析，为了减轻主题的不灵活性，重要的是非常仔细地设计主题树，并为未来的使用留下空间。如果您遵循这些策略，MQTT将是完美装置。 与消息队列区分开来
所以有很多关于MQTT的混乱，因为它的名字，把MQTT和消息队列混在一起了。我们将解释这个分歧，在我们的最后一篇**中，我们已经指出了这个名字，MQTT来自名为MQSeries的IBM产品，与之无关。但不管名字，MQTT和传统消息队列之间有什么区别？ 当使用消息队列时，每个传入的消息将被存储在该队列中，直到被任何客户端（通常称为消费者）拾取。否则，消息将被卡在队列中并等待获取，消息不可能被任何客户端处理，就像在MQTT中，如果没有人订阅主题。
另一个很大的区别是，传统的队列中只有一个消费者处理消息。因此，负载可以在特定队列的所有消费者之间分配。在MQTT中，如果订阅主题，每个订阅者都会收到消息。
队列比主题要僵硬得多，在使用队列之前，必须使用单独的命令创建它，只有在此之后，才有可能发布或使用消息，而在MQTT中，主题非常灵活，可以即时创建。
如果有什么不同见解，欢迎在评论中我们讨论。 学习总结
MQTT是基于发布和订阅机制的 发布者和接收者是解耦的，没有直接的联系 如何实现消息匹配对应是通过过滤实现的 MQTT是与消息队列机制是不同的
| 
楼主
标题置顶
标题高亮
