跳到主要内容

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

· 阅读需 7 分钟
信息

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个级别:

  1. 或“最多一次”——消息可以传递,也可不传递,但不应有重复:
  • 发布者的消息应该传递给中间人一次或零次;
  • 订阅者将从中间人那里收到消息一次或零次;
  1. 或“至少一次”——必须传递消息,但可以重复:
  • 发布者的消息应该传递给中间人一次或多次;
  • 订阅者将从中间人那里收到一次或多次消息;
  1. 或“刚好一次”——必须传递消息,并且只能传递一次:
  • 发布者的消息必须传递给中间人一次;
  • 订阅者必须从中间人那里获得一次消息。