Shifu物联网知识普及之mqtt篇——概览

信息

Shifu能够轻松接入使用MQTT协议的设备，让物联网开发变得更高效。Shifu是一个Kubernetes原生的物联网开发框架，开发者通过Shifu可以轻松实现连接、监控和控制任何物联网设备。Shifu将Kubernetes带入到物联网边缘计算场景中，助力实现物联网应用程序的可扩展性和高可用性。

引言

看到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. 或“刚好一次”——必须传递消息，并且只能传递一次：

• 发布者的消息必须传递给中间人一次；
• 订阅者必须从中间人那里获得一次消息。