装修网站怎么做的好处,怎样用eclipse做网站,wordpress同步微博内容,信阳做网站推广什么是MQTT
MQTT#xff08;Message Queuing Telemetry Transport#xff09;是一种轻量级、基于发布-订阅模式的消息传输协议#xff0c;适用于资源受限的设备和低带宽、高延迟或不稳定的网络环境。它在物联网应用中广受欢迎#xff0c;能够实现传感器、执行器和其它设备…什么是MQTT
MQTTMessage Queuing Telemetry Transport是一种轻量级、基于发布-订阅模式的消息传输协议适用于资源受限的设备和低带宽、高延迟或不稳定的网络环境。它在物联网应用中广受欢迎能够实现传感器、执行器和其它设备之间的高效通信。
为什么 MQTT 是适用于物联网的最佳协议
MQTT 所具有的适用于物联网特定需求的特点和功能使其成为物联网领域最佳的协议之一。它的主要特点包括
轻量级物联网设备通常在处理能力、内存和能耗方面受到限制。MQTT 开销低、报文小的特点使其非常适合这些设备因为它消耗更少的资源即使在有限的能力下也能实现高效的通信。可靠物联网网络常常面临高延迟或连接不稳定的情况。MQTT 支持多种 QoS 等级、会话感知和持久连接即使在困难的条件下也能保证消息的可靠传递使其非常适合物联网应用。安全通信安全对于物联网网络至关重要因为其经常涉及敏感数据的传输。为确保数据在传输过程中的机密性MQTT 提供传输层安全TLS和安全套接层SSL加密功能。此外MQTT 还通过用户名/密码凭证或客户端证书提供身份验证和授权机制以保护网络及其资源的访问。双向通信MQTT 的发布-订阅模式为设备之间提供了无缝的双向通信方式。客户端既可以向主题发布消息也可以订阅接收特定主题上的消息从而实现了物联网生态系统中的高效数据交换而无需直接将设备耦合在一起。这种模式也简化了新设备的集成同时保证了系统易于扩展。连续、有状态的会话MQTT 提供了客户端与 Broker 之间保持有状态会话的能力这使得系统即使在断开连接后也能记住订阅和未传递的消息。此外客户端还可以在建立连接时指定一个保活间隔这会促使 Broker 定期检查连接状态。如果连接中断Broker 会储存未传递的消息根据 QoS 级别确定并在客户端重新连接时尝试传递它们。这个特性保证了通信的可靠性降低了因间断性连接而导致数据丢失的风险。大规模物联网设备支持物联网系统往往涉及大量设备需要一种能够处理大规模部署的协议。MQTT 的轻量级特性、低带宽消耗和对资源的高效利用使其成为大规模物联网应用的理想选择。通过采用发布-订阅模式MQTT 实现了发送者和接收者的解耦从而有效地减少了网络流量和资源使用。此外协议对不同 QoS 等级的支持使得消息传递可以根据需求进行定制确保在各种场景下获得最佳的性能表现。语言支持物联网系统包含使用各种编程语言开发的设备和应用。MQTT 具有广泛的语言支持使其能够轻松与多个平台和技术进行集成从而实现了物联网生态系统中的无缝通信和互操作性。您可以阅读我们的 MQTT 客户端编程系列文章学习如何在 PHP、Node.js、Python、Golang、Node.js 等编程语言中使用 MQTT。
MQTT 的工作原理
要了解 MQTT 的工作原理首先需要掌握以下几个概念MQTT 客户端、MQTT Broker、发布-订阅模式、主题、QoS。
MQTT 客户端
任何运行 MQTT 客户端库的应用或设备都是 MQTT 客户端。例如使用 MQTT 的即时通讯应用是客户端使用 MQTT 上报数据的各种传感器是客户端各种 MQTT 测试工具也是客户端。
MQTT Broker
MQTT Broker 是负责处理客户端请求的关键组件包括建立连接、断开连接、订阅和取消订阅等操作同时还负责消息的转发。一个高效强大的 MQTT Broker 能够轻松应对海量连接和百万级消息吞吐量从而帮助物联网服务提供商专注于业务发展快速构建可靠的 MQTT 应用。
关于 MQTT Broker 的更多详情请参阅文章 2023 年最全面的 MQTT Broker 比较指南。
发布-订阅模式
发布-订阅模式与客户端-服务器模式的不同之处在于它将发送消息的客户端发布者和接收消息的客户端订阅者进行了解耦。发布者和订阅者之间无需建立直接连接而是通过 MQTT Broker 来负责消息的路由和分发。
下图展示了 MQTT 发布/订阅过程。温度传感器作为客户端连接到 MQTT Broker并通过发布操作将温度数据发布到一个特定主题例如 Temperature。MQTT Broker 接收到该消息后会负责将其转发给订阅了相应主题Temperature的订阅者客户端。
主题
MQTT 协议根据主题来转发消息。主题通过 / 来区分层级类似于 URL 路径例如
chat/room/1
sensor/10/temperature
sensor//temperatureMQTT 主题支持以下两种通配符 和 #。
表示单层通配符例如 a/ 匹配 a/x 或 a/y。#表示多层通配符例如 a/# 匹配 a/x、a/b/c/d。 注意通配符主题只能用于订阅不能用于发布。 关于 MQTT 主题的更多详情请参阅文章通过案例理解 MQTT 主题与通配符。
QoS
MQTT 提供了三种服务质量QoS在不同网络环境下保证消息的可靠性。QoS 0消息最多传送一次。如果当前客户端不可用它将丢失这条消息。QoS 1消息至少传送一次。QoS 2消息只传送一次。 关于 MQTT QoS 的更多详情请参阅文章 MQTT QoS 0, 1, 2 介绍。
MQTT 的工作流程
在了解了 MQTT 的基本组件之后让我们来看看它的一般工作流程
客户端使用 TCP/IP 协议与 Broker 建立连接可以选择使用 TLS/SSL 加密来实现安全通信。客户端提供认证信息并指定会话类型Clean Session 或 Persistent Session。客户端既可以向特定主题发布消息也可以订阅主题以接收消息。当客户端发布消息时它会将消息发送给 MQTT Broker而当客户端订阅消息时它会接收与订阅主题相关的消息。MQTT Broker 接收发布的消息并将这些消息转发给订阅了对应主题的客户端。它根据 QoS 等级确保消息可靠传递并根据会话类型为断开连接的客户端存储消息。
开始使用 MQTT快速教程
下面我们将通过一些简单的示例来展示如何使用 MQTT。在开始之前需要准备 MQTT Broker 和 MQTT 客户端。
准备 MQTT Broker–EMQX
EMQX
EMQ X (Erlang/Enterprise/Elastic MQTT Broker) 是基于 Erlang/OTP 平台开发的开源物联网 MQTT 消息服务器。Erlang/OTP 是出色的软实时(Soft-Realtime)、低延时(Low-Latency)、分布式(Distributed) 的语言平台。MQTT 是轻量的(Lightweight)、发布订阅模式(PubSub) 的物联网消息协议。
下载和安装
文档下载EMQX开源版本
web访问
http://localhost:18083 来查看Dashboard默认用户名是 admin密码是 public。
文档
EMQX文档
EMQX 快速入门指南EMQX Dashboard 介绍如何进行访问控制如何使用数据集成如何使用规则引擎EMQX 配置文件指南使用 EMQX REST API
准备 MQTT 客户端–MQTTX
MQTTX
MQTTX 是 EMQ 开源的一款优雅的跨平台 MQTT 5.0 客户端工具它支持 macOS、Linux 和 Windows并且支持 MQTT 消息格式转换。
MQTTX 的用户界面借助聊天软件的形式简化了页面的操作逻辑用户可以快速创建连接保存并同时建立多个连接客户端方便用户快速测试 MQTT/TCP、MQTT/TLS、和 MQTT/WebSocket 的 连接/发布/订阅 功能及其他特性。
windows客户端工具
下载https://mqttx.app/zh 文档https://mqttx.app/zh/docs
MQTTX CLI
MQTTX CLI 是 EMQ 开源的一款 MQTT 5.0 命令行客户端工具也是命令行上的 MQTTX旨在帮助开发者在不需要使用图形化界面的基础上也能更快的开发和调试 MQTT 服务与应用。 文档https://mqttx.app/zh/docs/cli
MQTTX Web
MQTTX Web 是一款开源的 MQTT 5.0 浏览器客户端也是一个在线 MQTT WebSocket 客户端工具。使用 WebSocket 在浏览器中连接到 MQTT帮助开发者更快地开发和调试 MQTT 服务和应用程序而不必在本地下载和安装 MQTTX。 在线地址https://mqttx.app/web-client#/recent_connections 文档https://mqttx.app/zh/docs/web
创建 MQTT 连接
具体文档查看 MQTT 协议入门基础知识和快速教程
MQTT入门
MQTT 协议入门基础知识和快速教程MQTT 发布/订阅模式介绍创建 MQTT 连接时如何设置参数通过案例理解 MQTT 主题与通配符MQTT会话详情MQTT QoS 0, 1, 2 介绍
MQTT进阶
保留消息Retained Messages遗愿消息Will Messages请求/响应Request/Response用户属性User Properties主题别名Topic Alias载荷格式指示与内容类型Payload Format Indicator Content Type共享订阅Shared Subscriptions订阅选项Subscription Options订阅标识符Subscription Identinfier保持连接Keep Alive消息过期间隔Message Expiry Interval最大报文大小Maximum Packet Size原因码以速查表Reason Code Quick Reference增强认证Enhanced Authentication控制报文Control Packets
MQTT编程
服务端
如何在 Python 中使用 MQTT如何在 Java 中使用 MQTT如何在 Node.js 项目中使用 MQTT如何在 PHP 项目中使用 MQTT如何在 Golang 中使用 MQTT如何在 Rust 中使用 MQTT开发指南使用 MQTTNet 库构建 .Net 物联网 MQTT 应用程序如何在 Dart 中使用 MQTT
前端
MQTT.js 入门教程使用 WebSocket 连接 MQTT 服务器如何在 Vue 项目中使用 MQTT如何在 React 项目中使用 MQTT如何在 Angular 项目中使用 MQTT如何在 Electron 项目中使用 MQTT
移动端
如何在 React Native 项目中使用 MQTTCocoaMQTT v2.0首个支持 MQTT 5.0 的 iOS 客户端Android 使用 Kotlin 连接 MQTT在 Flutter 项目中使用 MQTTAndroid MQTT TLS/SSL 认证
硬件
在树莓派上使用 MQTT在树莓派中使用 MicroPython 接入 MQTTESP32 连接到免费的公共 MQTT 服务器ESP8266 连接到免费的公共 MQTT 服务器ESP8266 MQTT 如何实现 LED 灯的远程控制通过 NodeMCU (ESP8266) 将传感器数据上传至 MQTT 云服务
MQTT术语表
Broker
有时我们也会直接将服务端称为 Broker这两个术语可以互换使用。
Clean Start
客户端可以在连接时使用这个字段来指示是期望从已存在的会话中恢复通信还是创建一个全新的会话。仅限 MQTT v5.0。
Client
使用 MQTT 协议连接到服务端的设备或应用程序并通过服务端完成发布订阅。
Client ID
Client ID 用于唯一标识客户端连接与会话MQTT 允许客户端自行指定 Client ID也支持由服务端统一为客户端分配 Client ID。
Connection
MQTT 客户端与 MQTT 服务端之间的网络连接。MQTT 客户端之间并不会直接建立连接。
Content Type
用来描述消息的内容类型方便接收方处理。可以使用 MIME 类型例如 text/plain也可以使用自定义的字符串来描述消息内容。仅限 MQTT v5.0。
Enhanced Authentication
MQTT v5.0 通过新增的 AUTH 报文实现了对增强认证的支持在原先通过 Username 和 Password 提供的密码认证和 Token 认证的基础上进行了扩展。
它更像是一种认证框架允许使用各种更安全的认证机制例如 SCRAM 认证就支持服务端和客户端互相确认对方的身份以抵御中间人攻击。
Flow Control
MQTT v5.0 引入了流控机制允许客户端和服务端根据自己的接收能力约定对方的最大消息发送速率避免了一方发送过快导致网络拥塞和接收方过载的问题。
Keep Alive
Keep Alive 表示客户端在传输完成一个 MQTT 控制报文到发送下一个报文两者之间允许空闲的最大的时间间隔。
如果没有其他控制报文可以发送客户端必须发送一个 PINGREQ 报文。
如果服务端在 1.5 倍的 Keep Alive 时间内没有收到任何客户端的控制报文它就会断开连接。
Message
通常指 PUBLISH 报文。
Message Expiry Interval
MQTT v5.0 允许客户端为消息设置过期时间避免在服务端中停留了较长时间的消息仍然被转发给订阅端。
MQTT over QUIC
MQTT over … 指的是 MQTT 运行在什么协议之上。常见的有 MQTT over TCP、MQTT over TLS 等。
MQTT 协议只要求基础传输层能够提供有序、可靠的双向传输字节流并未强制指定使用某种传输协议。
MQTT over QUIC 是 EMQX 对 MQTT 的一个扩展。相比于 TCPQUIC 能够有效减少连接开销和弱网环境下的消息延迟同时还具备多路复用、连接迁移、端到端加密等特性为现代移动互联网提供了一个更加灵活可靠的传输层。
MQTT v3.1.1
OASIS 技术委员会于 2014 年 10 月发布的 MQTT 规范。
MQTT v5.0
OASIS 技术委员会于 2019 年 3 月发布的 MQTT 规范也是目前最新的 MQTT 规范。MQTT v5.0 在引入大量新特性的同时仍然向后兼容 v3.1.1。
Packet
通常指 MQTT 的控制报文。MQTT 协议通过交换预定义的 MQTT 控制报文来通信。
例如用于连接的 CONNECT、AUTH仅限 MQTT v5.0 报文用于发布的 PUBLISH 报文以及用于订阅的 SUBSCRIBE 报文等等。
Packet Identifier
报文标识符用于在客户端和服务端之间唯一地标识一条 QoS 大于 0 的消息或一个订阅/取消订阅请求。
报文标识符的设置通常都在客户端和服务端的内部完成。
Payload
MQTT 报文中的有效载荷部分根据报文类型有效载荷的内容会有所不同。
对于 PUBLISH 报文来说有效载荷即消息的实际内容。而对于 SUBSCRIBE 报文来说有效载荷指的是订阅列表。
不过大部分情况下如无特别说明Payload 都是指 PUBLISH 报文中消息的实际内容。
Payload Format Indicator
用于指示消息内容包括遗嘱消息是否是 UTF-8 编码的字符串。仅限 MQTT v5.0。
PINGREQ PINGRESP
客户端需要及时发送 PINGREQ 报文告知服务端自己还活着。
服务端也需要及时响应 PINGRESP 报文以便客户端判断网络和服务端的活动状态。
Property
MQTT 为绝大部分的控制报文中都定义了一组可选属性。不同类型的控制报文有不同的可选属性。
例如 Session Expiry Interval 是 CONNECT 报文的一个可选属性Topic Alias 则是 PUBLISH 报文的一个可选属性。
Publish/Subscribe
发布订阅机制是 MQTT 协议的核心。它解耦了消息的发送方发布者和接收方订阅者引入了一个中间代理的角色来完成消息的路由和分发。
发布者和订阅者不需要知道彼此的存在他们之间唯一的联系就是对消息的一致约定例如消息将使用什么主题、消息将包含哪些字段等等。
通过发布订阅机制我们可以实现消息的广播、组播和单播。
QoS
MQTT 定义了三种 QoS 等级来分别提供不同的消息可靠性保证。每条消息都可以在发布时独立设置自己的 QoS。
QoS 0最多交付一次消息可能丢失。QoS 1至少交付一次消息可以保证到达但是可能重复到达。QoS 2只交付一次消息保证到达并且不会重复。
Reason Code
MQTT 通过 CONNACK 等响应报文中的 Reason Code 字段来指示操作结果。
MQTT v5.0 扩展了 Reason Code 以便反映更准确的结果并且令所有响应报文都支持了 Reason Code。
Reason String
Reason Code 通常是机器易读的所以 MQTT 还提供了 Reason String 来承载人类可读的内容在 Reason Code 的基础上进一步指示结果。仅限 MQTT v5.0。
Receive Maximum
用于声明服务端和客户端愿意同时处理的 QoS 1 和 QoS 2 的消息的最大数量对端在发送消息时需要遵守这个限制。仅限 MQTT v5.0。
Request Response
MQTT 的发布订阅机制使得发布端最多只能确保消息到达了服务端但不能确保消息到达了订阅端我们必须借助额外的请求响应机制。
MQTT v5.0 改善了对请求响应的支持请求方可以在请求中直接指定响应主题这样请求方和响应方无需再提前约定主题。同时他们还可以通过对比数据来确保请求和响应的正确匹配。
Retained Message
保留消息除了与正常消息一样被转发以外还会保留在 MQTT 服务端中。
当一个新的订阅被创建如果服务端中存在与该订阅匹配的保留消息那么这些保留消息就会被发送给订阅者。
服务端只能为每个主题存储一条最新的保留消息。
Security
MQTT 支持多种安全机制包括但不限于支持在传输层使用 TLS 来提供端到端的安全连接保护消息免受窃听、篡改或伪造在 MQTT 协议层面支持对客户端和服务端的身份验证以及对客户端的授权检查以确保只有授权用户才能访问特定的主题。
Server
在发布消息的客户端和订阅的客户端之间充当中介的设备或应用程序它的首要职责是将所有接收到的消息转发给匹配的订阅客户端。
Server Disconnect
MQTT v5.0 允许服务端发出 DISCONNECT 报文以便向客户端指示连接被关闭的具体原因。
Server Reference
MQTT v5.0 允许服务端通过 CONNACK 或者 DISCONNECT 报文中的服务端参考属性指示客户端临时或永久切换至另一台服务端。
Session
MQTT 的会话机制确保了 QoS 1、2 消息的协议流程得以实现。
会话是客户端与服务端之间的有状态交互存储了 QoS 1、2 消息的传输状态以及订阅信息等状态信息。
它可以仅持续和网络连接一样长的时间也可以跨越多个网络连接存在。我们通常将后者称为持久会话。
我们可以选择让连接从已存在的会话中恢复也可以选择从一个全新的会话开始。
Session Expiry Interval
会话过期时间。表示客户端连接断开后会话能够在服务端中保留多久仅限 MQTT v5.0。
Session Present
服务端通过这个字段告知客户端本次连接是之前会话的延续还是一个全新的会话以便客户端做出相应的调整。
Shared Subscription
MQTT v5.0 允许将客户端划分为多个订阅组消息仍然会被转发给所有订阅组但一个订阅组内的客户端将以随机、轮询等策略交替接收消息。
这使得订阅者能够以负载均衡的方式来消费消息。
一些 MQTT Server 例如 EMQX 在协议之外为非 MQTT v5.0 的设备提供了共享订阅的支持。
Subscription Identifier
客户端可以在订阅时指定订阅标识符服务端在转发与这些订阅匹配的消息时需要附上与之关联的订阅标识符。
在特定的使用场景下订阅标识符可以帮助减少需要传输的数据量或者帮助客户端确定为消息触发哪个回调。
Subscription Options
MQTT 允许客户端为自己每个订阅使用不同的订阅选项例如订阅建立时是否需要接收保留消息服务端可以向自己发送的消息的最大 QoS 等等。
MQTT v3.1.1 仅支持设置最大 QoS。
Topic
主题被用来标识和区分不同的消息它是 MQTT 消息路由的基础。发布者可以在发布时指定消息的主题订阅者则可以选择订阅自己感兴趣的主题来接收相关的消息。
Topic Alias
MQTT v5.0 允许发送端将主题名映射成由一个双字节整数表示的别名然后在消息传输时用别名替换原本的主题名以此降低带宽消耗。
Topic Filter
主题过滤器在订阅时使用可以包含主题通配符来同时订阅多个主题。
Topic Name
主题名在发布消息时使用不允许使用主题通配符。
Topic Wildcards
MQTT 提供了两种主题通配符分别是 表示的单层通配符和 # 表示的多层通配符。通配符只能在主题过滤器中使用。
Username Password
MQTT 在连接报文中提供了可选的 Username 和 Password 字段以实现对密码认证和 Token 认证的支持。
User Property
MQTT v5.0 允许客户端和服务端将自定义的、不限数量的字符串键值对作为元数据添加到除 PING 报文以外的所有控制报文当中以提供更好的可扩展性。
用户属性可以在客户端和服务端之间传递也可以在客户端和客户端之间传递这主要取决于具体的控制报文类型。
Will Delay Interval
用于指示遗嘱消息可以在连接断开后延迟多久发出仅限 MQTT v5.0。
Will Message
如果客户端不正常地断开连接那么该客户端在连接时设置的遗嘱消息就会被服务端转发给其他的客户端。
遗嘱消息和普通消息一样具有主题、QoS、Payload、保留消息标识位等字段。
$ Topic
以 $ 开头的主题必须由服务端来决定其使用方式和场景客户端不能仅出于自己的目的来随意使用这类主题。
例如 s h a r e 开头的主题用于共享订阅 share 开头的主题用于共享订阅 share开头的主题用于共享订阅SYS 开头的主题通常被服务端用于发布系统消息。
EMQX 还定义了 $delay 前缀用于实现消息的延迟发布。
MQTT FAQs
什么是 MQTT
MQTT 是用于物联网连接的 OASIS 标准它是一种基于发布订阅模式的、轻量级的消息传输协议专为受限设备和低带宽、高延迟和不可靠的网络设计并且能够提供一定的消息可靠性保证。得益于这些特性MQTT 在车联网、工业制造、移动通信等领域广泛应用。
目前 MQTT 的主要版本有 v3.1.1 和 v5.0v5.0 于 2019 年 3 月发布相比于 v3.1.1 引入了很多改进和增强目前市面上绝大部分的客户端 和代理都已经支持了 MQTT v5.0。
什么是 MQTT Broker
基于发布订阅模式的 MQTT 解耦了消息的发送方和接收方并且引入了 Broker 这个中间角色。Broker 是 MQTT 客户端之间消息传输的桥梁它的主要职责是从客户端接收消息并根据消息的主题将它们路由到适当的订阅者。
什么是 EMQX
EMQX 是一款开源的、云原生的分布式物联网 MQTT 消息服务器能够轻松支持数百万个并发连接并且可以通过集群部署扩展至 1 亿并发连接。在处理每秒百万级的消息吞吐的同时EMQX 还能保证超低的消息时延。
EMQX 提供了 SSL/TLS、密码认证、增强认证、ACL 等多种安全机制来保障数据安全提供了基于 SQL 的、能够实时过滤、转换与处理消息的规则引擎以及强大的管理监控功能。EMQX 最新的 5.0 版本还提供了全球首个 MQTT over QUIC 的实现可以有效减少连接开销和弱网环境下的消息延迟并具备多路复用、连接迁移等特性。
目前 EMQX 已经广泛地应用在车联网、工业制造、能源电力等领域。
EMQX 支持 TLS 吗
是的。EMQX 提供了非常完整的 SSL/TLS 能力支持包括支持单/双向认证、X.509 证书认证、SNI 等等。
EMQX 除了支持为包括 MQTT 在内的所有客户端连接启用 TLS以保证接入和消息传输安全以外还支持为与其他所有外部资源的连接启用 TLS以确保访问外部资源时的数据安全。
什么是 MQTT 主题
主题被用来标识和区分不同的消息它是 MQTT 消息路由的基础。发布者可以在发布时指定消息的主题订阅者则可以选择订阅自己感兴趣的主题来接收相关的消息。
MQTT 和 EMQX 有什么区别
MQTT 是一个消息传输协议它广泛地应用在物联网等领域。MQTT 需要一个服务端来为所有客户端路由和分发所有消息而 EMQX 就是这个服务端的具体实现。EMQX 也是目前全球最受欢迎的开源 MQTT 消息服务器之一它提供了对 MQTT v3.1、v3.1.1 以及 v5.0 协议标准的完整支持。
MQTT 和 AMQP 有什么区别
MQTT 和 AMQP 都是运行在 TCP/IP 之上的二进制消息传递协议也都是开放的标准协议。
但 MQTT 主要为高延迟、低带宽和不可靠的网络而设计使用发布订阅模式支持通过主题路由消息。MQTT 拥有更轻巧的报文结构对于资源受限的设备更加友好。MQTT 还提供了遗嘱消息、保留消息、会话等专为运行在不可靠网络下的设备设计的功能。
而 AMQP 则旨在提供通用的消息队列协议确保业务消息在应用程序或者服务端之间安全高效地传输它提供了多种不同的路由规则来满足更复杂的应用场景目前 AMQP 广泛地应用于商业领域。
MQTT 和 Kafka 有什么区别
MQTT 和 Kafka 是完全不同的技术虽然它们具有一些类似的特性比如都基于发布订阅模式都通过主题来路由消息等等。
但实际上Kafka 更多地是专注于数据的存储和读取针对实时性高的流式数据处理场景。而 MQTT 则侧重于海量的设备连接和主题路由并且在不稳定的网络环境中进行实时的、可靠的消息交换。所以MQTT 和 Kafka 的最大差异在于它们有着不同的适用场景解决的是不同的问题。
在实际的生产应用中MQTT 和 Kafka 经常会结合一起使用。MQTT 代理解决海量终端设备的接入问题并将汇入的海量终端数据转发给 Kafka再由 Kafka 分发给不同的业务应用程序进行进一步的消息分析和处理。
EMQX 是免费的吗
是的EMQX 是一个基于 Apache 2.0 许可证完全开源的 MQTT 消息服务器从 2013 年在 Github 上开源至今EMQX 已经收获了超过 11K 的 Star 数。你可以在 EMQX 官网或者 Github 免费下载使用 EMQX。
除了 MQTTEMQX 还支持哪些协议
除了 MQTT 协议EMQX 还支持 MQTT-SN、CoAP、STOMP 以及 LwM2M 多种其他物联网协议并且允许接入的客户端跨协议通信。
EMQX 支持哪个 MQTT 版本
EMQX 提供了对所有协议版本的完整的 MQTT 支持包括 MQTT v3.1、v3.1.1 以及 v5.0并且允许不同协议版本的客户端同时接入。
MQTT 有多安全
MQTT 提供了多项安全机制通过密码认证、Token 认证或者支持多种认证算法的增强认证机制可以实现对客户端和服务端的身份验证再配合服务端的权限检查可以确保只有经过身份验证的客户端才能访问权限以内的数据。
MQTT 还支持使用 SSL/TLS 进行加密通信以保护数据的隐私性和完整性。
需要注意的是最终的安全性仍然取决于您的具体实施。比如是否安全地存储了密码是否在 TLS 中使用了足够安全的加密套件等等。
MQTT 使用 TCP 还是 UDP
MQTT 协议要求基础传输层能够提供有序、可靠的双向传输字节流所以 TCP 协议通常是 MQTT 的首要选择。
不过 MQTT 并未强制指定使用某种传输协议。虽然无法保证消息有序到达的 UDP 并不适合直接作为 MQTT 的底层传输协议但是基于 UDP 实现的 QUIC由于集成了 TCP 和 TLS 的所有优点并且解决了连接开销、连接不可迁移等缺点所以也非常适合作为 MQTT 的传输协议。
EMQX 能否代替 RabbitMQ
EMQX 的核心是 MQTTRabbitMQ 的核心是 AMQP他们有着不同的设计目标和用例。EMQX 是一个高性能、可扩展、功能丰富的 MQTT 消息服务器针对物联网和 M2M 通信进行了优化。EMQX 旨在处理海量的并发连接和消息吞吐使其适用于需要低延迟和实时通信的应用程序。
RabbitMQ 则更多的应用在不同系统间的数据交流和传递上。与 Kafka 类似很多时候RabbitMQ 与 EMQX 结合使用能够获得更好的效果。
MQTT 比 AMQP 快吗
单纯比较协议之间的性能差异是没有意义的这更多的取决于具体用例的实现。即便是同一种协议的不同实现也可能存在较大的性能差异。根据应用场景来选择协议根据期望的性能来对协议的具体实现进行选型会是一个更加合理的方案。
