消息队列MQ

教你轻松理解MQTT ——(1)概述

本文主要是介绍教你轻松理解MQTT ——(1)概述,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

引言

看到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/shifu,告诉我你的想法!

本文由边无际授权发布

这篇关于教你轻松理解MQTT ——(1)概述的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!