Shifu能够轻松接入使用MQTT协议的设备，让物联网开发变得更高效。Shifu是一个Kubernetes原生的物联网开发框架，开发者通过Shifu可以轻松实现连接、监控和控制任何物联网设备。Shifu将Kubernetes带入到物联网边缘计算场景中，助力实现物联网应用程序的可扩展性和高可用性。
引言
看到MQTT，你可能认为是“MQ Telemetry Transport”的缩写。 这个说法放在以前可能是对的，但现在就有待商榷了。目前的MQTT不是任何单词的缩写，就单指MQTT。请注意，MQ也不是首字母缩写词，而是IBM旗下一产品的名称，并不代表“Message Queue”。 背后的原因是该协议的应用已经不限于遥测传输。MQTT现在已经将目光放在了整个物联网领域。在成为物联网通信领域黄金标准的道路上，MQTT正吸引着全球越来越多用户的关注。然而，目前只有少数在线资源可以为我们提供该协议的完整指南，这也是作者撰写本系列文章的目的——为任何想深入了解IoT星球的人提供MQTT的详细介绍：
- 概述
- Pub/Sub的工作原理
- 保证QoS
- 将MQTT连接到Kafka
- 使用MQTT与真实设备进行交互
本文是MQTT简介系列的第一篇。通过本文，我们将快速浏览MQTT的一些基本术语。
MQTT工作原理简介
假设有如下设置：
- 发布者：我们房间里的一支温度计，发布带有“room1”标签的“温度”话题。
- 订阅者：我们房间里的一台笔记本电脑，订阅带有标签“room1”的“温度”话题。
- 中间人：在我们房间的服务器上运行。
- 话题：“温度”。 在“温度”话题下标记：“room1”。
温度消息的完整路径是：
- 温度计向中间人发布话题“温度”和标签“room1”的温度消息。
- 中间人检查谁订阅了话题和标签，然后将消息路由到笔记本电脑。
- 笔记本电脑收到消息。
Pub/Sub
在典型的客户端 - 服务器模式下，客户端和服务器需要相互了解，是强耦合系统示例。可问题是，服务器本身需要维护客户端注册表，这使得它变得复杂、容易出错并且不知何故会出现单点故障。
MQTT则使用Pub/Sub模式来解耦这个系统。
高级架构由三个组件组成：发布者——中间人——订阅者。发布者发布话题，订阅者订阅话题，而中间人则介于两者之间，主要负责过滤消息并确保订阅者只得到它想要的消息。我们也称MQTT中间人的发布者和订阅者为“客户”，表示他们都是中间人的客户； 因此，在此定义中，“服务器”是中间人。 中间人通过话题和话题下的标签过滤消息。话题是可用于对消息进行分组的“类型”或“类”，标签是话题的“子类型”或“子类”。 一旦发布者在话题和/或标签下向中间人发布消息，只有订阅相同话题和/或标签的订阅者才能从中间人获取消息。在这种情况下，发布者和订阅者都需要知道他们正在处理的话题和/或标签。
消息队列
MQTT可以被视为完全为物联网消息传递量身定制的消息队列。与Kafka等分布式系统中的传统消息队列系统相比，MQTT在空间和时间上都具有轻量级和更快速的特点。 MQTT更倾向于使用内存来存储吞吐量非常低的消息，并要求任何实现都支持动态添加/删除话题，以实现超低延迟和高灵活性。 你始终可以将MQTT与其他消息队列（如 Kafka）连接起来使用。
服务质量 (QoS)
顾名思义，QoS定义了中间人为客户（发布者和订阅者）服务的工作质量。客户端在与中间人通信时需要告诉中间人QoS的级别。
QoS共有3个级别：
- 或“最多一次”——消息可以传递，也可不传递，但不应有重复：
- 发布者的消息应该传递给中间人一次或零次；
- 订阅者将从中间人那里收到消息一次或零次；
- 或“至少一次”——必须传递消息，但可以重复：
- 发布者的消息应该传递给中间人一次或多次；
- 订阅者将从中间人那里收到一次或多次消息；
- 或“刚好一次”——必须传递消息，并且只能传递一次：
- 发布者的消息必须传递给中间人一次；
- 订阅者必须从中间人那里获得一次消息。