引言

看到MQTT，你可能认为是“MQ Telemetry Transport”的缩写。 这个说法放在以前可能是对的，但现在就有待商榷了。目前的MQTT不是任何单词的缩写，就单指MQTT。请注意，MQ也不是首字母缩写词，而是IBM旗下一产品的名称，并不代表“Message Queue”。

背后的原因是该协议的应用已经不限于遥测传输。MQTT现在已经将目光放在了整个物联网领域。在成为物联网通信领域黄金标准的道路上，MQTT正吸引着全球越来越多用户的关注。然而，目前只有少数在线资源可以为我们提供该协议的完整指南，这也是作者撰写本系列文章的目的——为任何想深入了解IoT星球的人提供MQTT的详细介绍：

1. 概述

2. Pub/Sub的工作原理

3. 保证QoS

4. 将MQTT连接到Kafka

5. 使用MQTT与真实设备进行交互

本文是MQTT简介系列的第一篇。通过本文，我们将快速浏览MQTT的一些基本术语。

MQTT工作原理简介

假设有如下设置：

发布者：我们房间里的一支温度计，发布带有“room1”标签的“温度”话题。

订阅者：我们房间里的一台笔记本电脑，订阅带有标签“room1”的“温度”话题。

中间人：在我们房间的服务器上运行。

话题：“温度”。

在“温度”话题下标记：“room1”。

温度消息的完整路径是：

1. 温度计向中间人发布话题“温度”和标签“room1”的温度消息。
2. 中间人检查谁订阅了话题和标签，然后将消息路由到笔记本电脑。
3. 笔记本电脑收到消息。

Pub/Sub

在典型的客户端 - 服务器模式下，客户端和服务器需要相互了解，是强耦合系统示例。可问题是，服务器本身需要维护客户端注册表，这使得它变得复杂、容易出错并且不知何故会出现单点故障。

MQTT则使用Pub/Sub模式来解耦这个系统。

高级架构由三个组件组成：发布者——中间人——订阅者。发布者发布话题，订阅者订阅话题，而中间人则介于两者之间，主要负责过滤消息并确保订阅者只得到它想要的消息。我们也称MQTT中间人的发布者和订阅者为“客户”，表示他们都是中间人的客户； 因此，在此定义中，“服务器”是中间人。
中间人通过话题和话题下的标签过滤消息。话题是可用于对消息进行分组的“类型”或“类”，标签是话题的“子类型”或“子类”。 一旦发布者在话题和/或标签下向中间人发布消息，只有订阅相同话题和/或标签的订阅者才能从中间人获取消息。在这种情况下，发布者和订阅者都需要知道他们正在处理的话题和/或标签。

消息队列

MQTT可以被视为完全为物联网消息传递量身定制的消息队列。与Kafka等分布式系统中的传统消息队列系统相比，MQTT在空间和时间上都具有轻量级和更快速的特点。 MQTT更倾向于使用内存来存储吞吐量非常低的消息，并要求任何实现都支持动态添加/删除话题，以实现超低延迟和高灵活性。

你始终可以将MQTT与其他消息队列（如 Kafka）连接起来使用。

服务质量 (QoS)

顾名思义，QoS定义了中间人为客户（发布者和订阅者）服务的工作质量。客户端在与中间人通信时需要告诉中间人QoS的级别。

QoS共有3个级别：

0，或“最多一次”——消息可以传递，也可不传递，但不应有重复：

— 发布者的消息应该传递给中间人一次或零次；

— 订阅者将从中间人那里收到消息一次或零次；

1，或“至少一次”——必须传递消息，但可以重复：

— 发布者的消息应该传递给中间人一次或多次；

— 订阅者将从中间人那里收到一次或多次消息；

2，或“刚好一次”——必须传递消息，并且只能传递一次：

— 发布者的消息必须传递给中间人一次；

— 订阅者必须从中间人那里获得一次消息。

一个小广告：我最近一直在做的事
我最近开发了一个名为Shifu的开源物联网开发框架，我很想听听您的意见。
Shifu是一个高度可扩展的框架，允许开发人员轻松控制物联网设备。Shifu通过CRD来扩展Kubernetes的功能，允许开发人员访问物联网设备的全部功能，甚至可以编写设备本身不具备的新功能。这简化了传统物联网应用程序的开发，大大提高了物联网应用程序的效率、质量和可重用性。*

欢迎大家登录https://github.com/Edgenesis/...，告诉我你的想法！

本文由边无际授权发布