Mqtt

作者：陶德坤，EMQX Cloud 开发者。 作为一名后端开发人员，我常常须要同时运行多个 Jetbrains IDE （集成开发环境），所以常常面临笔记本电脑过热问题。我曾尝试过各种散热办法，从传统的风扇到更先进的半导体冷却系统，但这些办法都带来了新的问题，如乐音和耗电等。 因而，我设计了一个智能的液冷散热解决方案：通过引入内部水冷零碎、利用微控制器 ESP32、MQTT 服务器 EMQX Cloud Serverless 以及容器化的部署平台 Fly.io 来实时监测和管制水温。以下是该解决方案的详述，心愿能为其余物联网开发者带来灵感： <center>作者 DIY 的物联网智能液冷散热零碎</center> 技术选型我心愿这套零碎不仅有功能性，还具备可靠性和效率，以确保水温监控零碎的稳固运行。以下是我筛选的技术栈： ESP32：在多种抉择中，ESP32 微控制器因其集成了 Wi-Fi 和蓝牙性能，以经济高效的特点而怀才不遇。这款芯片为物联网我的项目提供了弱小的性能反对，同时老本可控又不就义功能性。DS18B20 水温传感器：对于温度监控，DS18B20 是我的首选，因为它提供了准确的数字温度读数和杰出的耐水性能。这款传感器与 ESP32 可协同工作，确保了水温监控零碎的准确性和稳定性。EMQX Cloud Serverless MQTT Broker：在泛滥消息中间件中，EMQX Cloud 因其高性能、可靠性以及 Serverless MQTT 服务在解决大量并发连贯和音讯路由方面的卓越体现而受到青眼，这些个性对于确保设施间通信的顺畅至关重要。Python 和 Flask：抉择 Python 是因为它的表达力强且库函数丰盛，Flask 则轻量级且高度灵便，能适应疾速开发和部署的需要，这对于迅速实现我的项目原型至关重要。Fly.io：Fly.io 的寰球分布式边缘托管服务可能将容器转换为微虚拟机，提供了一个独特的平台。这不仅放慢了利用的部署速度，还大大减少了数据传输的提早，为用户提供了靠近实时的体验。我的项目施行我的项目的施行阶段是一个将创意转化为理论解决方案的过程。在这个过程中，首先要确保 EMQX Cloud Serverless 的正确配置，而后是硬件的集成，后端服务的开发，最初是零碎的部署和测试。 Serverless MQTT Broker 配置EMQX Cloud Serverless 提供收费配额，对于咱们的利用场景来说，这些配额齐全可能笼罩所需的老本，这也是我抉择 EMQX Cloud Serverless 部署的次要起因之一。另外，它默认反对传输层平安协定（TLS），为咱们的数据传输提供了强有力的加密保障，确保数据在传输过程中的机密性、完整性和身份验证，升高了数据泄露或被篡改的危险。 以下是配置 EMQX Cloud Serverless 的具体步骤： 创立 Serverless MQTT Broker: 登录到 EMQX Cloud 控制台，并导航至 "Create Deployment" 页面。抉择 "Serverless" 部署类型，并按需配置部署。例如区域、SpendLimit 等。实现配置后，点击 "Create" 按钮，零碎会主动创立 Serverless MQTT Broker。增加认证信息: ...

EMQX Enterprise 5.5.0 版本已正式公布！ 在这个版本中，咱们引入了一系列新的性能和改良，包含对 Elasticsearch 的集成、Apache IoTDB 和 OpenTSDB 数据集成优化、受权缓存反对排除主题等性能。此外，新版本还进行了多项改良以及 BUG 修复，进一步晋升了整体性能和稳定性。 新增 Elasticsearch 数据集成Elasticsearch 是一个分布式的搜寻和数据分析引擎，可能提供多样化数据的全文搜寻、结构化搜寻以及剖析等性能。在这个版本中，EMQX 新增了对 Elasticsearch 的数据集成，反对数据的插入、更新和删除操作，这意味着设施数据能够被写入到 Elasticsearch，用户能够灵便地应用 Elasticsearch 的搜寻和剖析能力对数据进行解决。 设施数据写入到 Elasticsearch 后，用户能够灵便的应用 Elasticsearch 的搜寻和剖析能力对数据进行解决。典型的应用场景包含物联网设施的事件和日志监测、地理位置数据（Maps）的解决以及终端平安监测。例如，物联网设施会生成大量的日志数据，这些数据能够被发送到 Elasticsearch 中进行存储和剖析。通过连贯到可视化工具，例如 Kibana，能够依据这些日志数据生成图表，实时展现设施状态、操作记录以及谬误音讯等信息。 Apache IoTDB 与 OpenTSDB 数据集成优化Apache IoTDB 与 OpenTSDB 数据集成在这个版本中失去了优化，当初反对配置数据写入模板，通过指定每个字段的工夫戳、字段名称、数据类型，实现灵便的数据写入，使得数据集成开发更加疾速和灵便。 InfluxDB, IoTDB 与 TDengine 数据集成反对批量设置写入字段在工业、车联网等利用中，时序类数据集成开发中，存在一条音讯蕴含数百乃至更多数据点位的场景。要配置将它们从音讯中提取，并一一对应存储到数据库中是一个反复且简单的工作。 为了解决这个问题，EMQX 提供了批量设置性能，用户能够通过 CSV 文件编辑要写入的字段名称以及从 Payload 中的取值形式，将其通过 Dashboard 进行导入，实现对应数据集成的疾速配置。目前反对的数据集成有 InfluxDB、Apache IoTDB, 以及 TDengine。 音讯桥接 SysKeeper 穿透反对在电力生产零碎的网络安全要求下，生产控制区、生产非控制区和生产管理区之间的网络通讯须要通过单向网闸设施保障网络安全。 EMQX 在数据集成中新增了正向网闸 SysKeeper 2000 穿透性能，通过配置能够启用此性能，进行 EMQX 音讯在不同生产区之间的桥接传输。这一性能确保合乎规章制度的状况下，实现了两个生产区之间数据通信，为电力行业物联网利用落地提供了定制化的反对，助力电力系统的平安、高效经营。 ...

EMQX Enterprise 5.4.0 版本已正式公布！ 新版本提供 OpenTelemetry 分布式追踪与日志集成性能，新增了凋谢充电协定 OCPP 协定接入能力，并为数据集成增加了 Confluent 反对。此外，新版本还进行了多项改良以及 BUG 修复，进一步晋升了整体性能和稳定性。 OpenTelemetry 分布式追踪与日志集成在 EMQX v5.2.0 中，EMQX 提供了 OpenTelemetry 指标（Metrics）的集成，本次公布中，EMQX 进一步提供了分布式追踪（Traces）与日志（Logs）的集成，齐全实现了 OpenTelemetry 可观测性框架所需的性能。 分布式追踪（Traces）OpenTelemetry 分布式追踪是一个用于追踪申请在分布式系统中的流动的标准，用于追踪申请在分布式系统中的流动状况，并提供可视化剖析申请的性能和行为的能力。在 MQTT 场景下，这一概念能够实现逾越 MQTT 音讯传输中的不同参与者（发布者-MQTT 服务器-订阅者）的申请追踪。 EMQX 遵循 W3C 的 Trace Context MQTT 标准实现了端到端的分布式追踪性能：客户端在公布时为音讯增加 traceparent 用户属性，Traces 将记录音讯在 EMQX 集群节点以及订阅者之间的流转状况。对于不反对设置用户属性的 MQTT v3.1/3.1.1 客户端，也能够配置 EMQX 在外部主动为音讯增加追踪 ID 实现分布式追踪。 借助 OpenTelemetry 分布式追踪，EMQX 系统管理员或开发者能够实时监测和剖析物联网利用的性能和行为，并在呈现故障时疾速定位并排除故障。 日志（Logs）与基于文件的日志一样，OpenTelemetry 日志同样用于记录要害事件、状态信息和谬误音讯，帮忙开发人员和运维团队了解应用程序的行为和故障排查。 不同的是，OpenTelemetry 日志应用了规范化的日志记录格局，使得日志更易于解析、剖析和解决。首次之外 OpenTelemetry 日志还反对在记录中增加丰盛的上下文信息，如 Trace ID、标签、属性等。 EMQX 反对同时开启 OpenTelemetry 指标、追踪与日志性能。指标用于实时状态监测，追踪数据显示申请的流程和路径，而日志数据能够提供每个流程上更多的细节和上下文信息，三者互相集成能够建设一个对立的视图和剖析平台，造成一个残缺的观测解决方案。通过对立的平台，用户能够更高效地治理和利用数据以取得全面的应用程序观测能力，从而精确地定位和解决问题，大大晋升开发人员和运维团队的工作效率。 凋谢充电协定 OCPP 协定网关OCPP (Open Charge Point Protocol) 是一个连贯充电桩与地方管理系统的凋谢通信协议，旨在为电动汽车充电基础设施提供对立的通信标准。 ...

除了前几篇文章中提到的认证办法，本文将对其余认证办法进行深入分析和探讨。 具体而言，咱们将深刻理解基于 Token 的认证和 OAuth 2.0，论述它们的原理并展现它们在 MQTT 中的利用。 基于 Token 的认证让咱们先来认识一下基于 Token 的认证，理解它相较于传统的用户名和明码认证的一些劣势。 什么是基于 Token 的认证？简略来说，基于 Token 的认证应用 Token 来验证客户端身份，而不是应用传统的凭据（如用户名和明码）。这个过程相似于应用电子门卡进入酒店房间。当您向前台出示身份证时，他们会提供一张电子门卡，让您可能关上酒店房门。这张电子门卡在您入住期间起到了 Token 的作用，您无需每次进入房间时都向前台证实身份，只需刷卡即可。 Token 的一个重要个性是其具备有效期限度，能够在到期后生效。例如，您的酒店门卡在退房后将生效。然而，您可能会入住另一家酒店并拿到新房间的门卡。因而，相较于用户名和明码，Token 更加灵便且易于治理。酒店房门上的电子门卡阅读器无需记录无效的用户名和明码，只需验证门卡上的房间号码和有效期即可。 上面咱们将深入研究一些实用于 MQTT 的基于 Token 的认证办法。 基于 Token 的 MQTT 认证办法在 MQTT 中，咱们通常应用 JWT 来实现令牌认证。 JWT（JSON Web Token）是一种在 MQTT Broker 中验证客户端身份的简洁形式。客户端向 Broker 发送一个签名的 JWT Token，Broker 依据该 Token 验证客户端身份。Broker 不须要保留客户端的用户名和明码。 JWT Token 由以下局部组成： 头部：用 Base64 编码 - 阐明生成签名所采纳的算法。有效载荷：用 Base64 编码 - 携带能够验证客户端身份的申明。签名：将头部和有效载荷连贯后用 Base64 编码，再用密钥对其签名。下图显示了 JWT 的构造： ...

引言规定引擎是一种可能依据输出数据依照预设规定进行决策或执行动作的软件系统。本文将向您介绍 EMQX MQTT Broker 的规定引擎性能，并论述其在 MQTT 音讯转换和数据集成方面的重要作用。同时，咱们还将提供一份疾速入门指南，通过实例帮忙您疾速上手 MQTT 规定引擎。 MQTT 的规定引擎是什么？MQTT 是一种高效牢靠的音讯传输协定，特地实用于低带宽、高提早网络（在物联网畛域非常常见）。在 MQTT 的公布/订阅模型中，MQTT Broker 扮演着要害角色，负责接管发布者发送的音讯并将其牢靠高效地分发给订阅者，确保音讯的顺利传递。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1254773?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

引言MQTT 是一种轻量级的消息传递协定，实用于物联网利用实现设施间通信。 作为一款支流的开源 MQTT Broker，EMQX 可能提供高扩展性、可靠性和安全性的 MQTT 消息传递服务。 借助广泛应用的基础设施即代码（IaC）工具 Terraform，您能够轻松在 GCP 上主动部署 EMQX MQTT Broker，从而简化和标准 MQTT 基础设施的设置和治理。 本文将领导您如何设置 GCP 我的项目、创立服务账户、编写 Terraform 配置文件，实现轻松部署 EMQX MQTT Broker。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1246859?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

引言Sparkplug 是一种为 SCADA 零碎量身定制的工业物联网通信协议。它为工业设施和利用提供了一种规范的通信格局，实现了不同厂商设施的互操作性。Sparkplug 标准由 Cirrus Link Solutions 和 Eclipse Foundation 独特制订。它是凋谢的，不属于某一家公司。因而，它给 Sparkplug 社区带来了以下好处： 促成不同零碎和技术之间的顺畅合作，晋升效率、降低成本，为消费者提供更多抉择。保障不同厂商产品的兼容性和协作性，减少消费者的抉择，促成厂商之间的良性竞争。通过推动合作、分享想法和计划，激发翻新，促成新产品、新服务和新技术的倒退。进步透明度、建设信赖，升高厂商锁定或依赖繁多供应商的危险。让产品和服务对各种用户凋谢，包含残障人士。残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1244369?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

CAN Bus 是一种广泛应用于汽车和工业畛域的通信协议，它可能让多个设施在同一网络中进行交互。而 MQTT 是一种广泛应用于物联网畛域的通信协议，作为一种轻量级的公布-订阅音讯传输协定，它无效地促成了机器之间的通信。 通过将 CAN Bus 数据桥接到 MQTT，可能实现 CAN Bus 设施与物联网平台和利用的集成。只管市场上存在多种解决方案和工具能够实现这一指标，但它们通常只传输原始的二进制 CAN 数据，这导致对信号进行过滤和解决十分不不便。 在本文中，咱们将介绍一种全新的解决方案，通过应用 开源边缘流式 SQL 引擎 eKuiper，灵便地从 CAN Bus 提取有意义的数据和所需的信号，实现从 CAN Bus 到 MQTT 的无缝桥接。 CAN Bus 的工作原理CAN Bus 是一种通信零碎，它可能让车辆中的不同设施互相传递数据。它还能提供许多有用的车辆信息，例如速度、油量、发动机温度和诊断码等。然而，从 CAN Bus 中获取和解读这些信息并不是一件容易的事件，因为它们通常以二进制模式进行存储。 深刻理解 CAN Bus ，欢送浏览：车联网 CAN Bus 协定介绍与数据实时流解决CAN 帧咱们能够从 CAN Bus 接管 CAN 帧流，其中蕴含咱们感兴趣的二进制模式的信号。每个 CAN 帧都蕴含 ID、数据长度码（DLC）和有效载荷。 ID 用来标识帧中数据的类型。DLC 用来指定帧中数据的字节数。有效载荷是帧中携带的理论数据。CAN 协定有多种类型，它们在 ID 和有效载荷长度的定义上略有不同。上面是一个 CAN 2.0A 帧的例子，其 ID 为 11 位，有效载荷长度最多为 8 字节。 有效载荷由一系列信号组成。每个信号都有名称、长度和值。 ...

引言工业零碎须要确保数据的无缝替换，因而对于高效、平安的通信协议具备极高的依赖性。MQTT Sparkplug 和 OPC UA 是两个常常被提到的工业协定。本文将全面比拟 MQTT Sparkplug 和 OPC UA 以及它们的衍生版本，帮忙您更分明地理解哪种协定更适宜您的需要。 OPC Classic 和 OPC UAOPC UA 的前身是 OPC Classic（也称为 OPC DA 或 OPC Data Access），是由 OPC 基金会开发的一套工业自动化规范。OPC Classic 标准于 1996 年首次公布，它定义了一种标准化的办法，用于在软件应用和工业硬件设施（如传感器、控制器和可编程逻辑控制器）之间替换数据。 然而，OPC Classic 有个显著毛病：它与微软 Windows 操作系统及其专有的 DCOM 技术严密耦合。这种依赖性重大影响了协定的可用性、扩展性、互操作性、安全性和平台独立性，这对一个凋谢规范来说是微小的制约。 为了克服这些限度，OPC 基金会于 2006 年开始开发了 OPC UA (OPC Unified Architecture) 作为 OPC Classic 标准的后继者。这两种标准在性能上是等效的，但应用不同的底层通信技术。此外，OPC Classic DA 3.0 也于同年公布，并且至今仍在应用中。 为物联网而生的协定：MQTT 的演进在 20 世纪 90 年代末，Andy Stanford-Clark 和 Arlen Nipper 参加了一个对于管道监测的我的项目，该我的项目须要一种轻量级协定，用于与近程传感器和设施进行通信。该我的项目要求在低功耗、低带宽的环境下实现监测性能。然而，过后的音讯传输协定，如 HTTP 和 SMTP，被认为过于臃肿和低效，不适宜这种非凡的场景。 ...

在本系列之前的文章中咱们提到，借助 MQTT CONNECT 报文中的 Username 和 Password 字段，咱们能够实现一些简略的认证，比方明码认证、Token 认证等。为了进一步保障物联网零碎的平安，在本期文章中，咱们将一起理解另一种认证机制：加强认证。 什么是加强认证？加强认证是 MQTT 5.0 新引入的认证机制。事实上，咱们用认证框架来形容它更为适宜，因为它容许咱们套用各种比明码认证更加平安的身份验证办法。 不过更平安，另一方面则意味着更简单，这类身份验证办法例如 SCRAM 通常都要求一次以上的认证数据往返。这导致由 CONNECT 与 CONNACK 报文提供的一次往返的认证框架变得不再实用，所以 MQTT 5.0 专门为此新增了 AUTH 报文，它可能反对任意次数的认证数据的往返。这使得咱们能够将质询-响应格调的 SASL 机制引入到 MQTT 中。 加强认证解决了什么问题？在咱们议论这个问题之前，咱们须要晓得，为什么明码认证依然不够平安？ 事实上，即便咱们曾经应用加盐与哈希的形式来存储明码，尽可能晋升了明码存储的安全性。然而为了实现认证，客户端不得不在网络中明文传输明码，这就使明码有了被透露的危险。即便咱们应用 TLS 加密了通信，也仍有可能因为应用了较低的 SSL 版本、不够平安的明码套件、不非法的 CA 证书等等起因导致被攻击者窃取到明码这类敏感数据。 另外，简略的明码认证只能让服务端验证客户端的身份，却不能让客户端验证服务端的身份，这使得攻击者有机会假冒服务端来获取客户端发送的敏感数据。而这就是咱们通常所说的中间人攻打。 而通过加强认证，咱们能够抉择应用 SASL 框架下的安全性更强的认证办法，它们有些能够防止在网络中传输明码，有些能够让客户端和服务端相互验证对方的身份，有些则两者皆备，这仍取决于咱们最终抉择的认证办法。 常见的可用于加强认证的 SASL 机制DIGEST-MD5DIGEST-MD5 是在简略认证平安层（SASL）框架下的一种身份验证机制。它基于 MD5（Message Digest 5）散列算法，应用质询-响应机制来验证客户端和服务器之间的身份。它的长处在于客户端不须要在网络上传输明文明码。 简略来说，就是当客户端申请拜访受爱护资源时，服务端将返回一个 Challenge，其中蕴含了一次性的随机数和一些必要参数，客户端须要应用这些参数加上本人持有的用户名明码等数据，生成一个响应并返回给服务端，服务端将应用完全相同的形式生成冀望的响应，而后与收到的响应进行比拟，如果两者匹配，则身份验证通过。这免去了明码因为受到网络窃听而透露的危险，并且因为连贯时应用的是一次性的随机数，所以也加强了对重放攻打的防御能力。 但须要留神，DIGEST-MD5 只提供了服务端对客户端的身份验证，但没有提供客户端对服务端的身份验证，所以它并不能避免中间人攻打。另外，因为 MD5 目前曾经不再平安，所以更举荐应用 SHA-256 这类抗碰撞能力更强的哈希函数来代替它。 SCRAMSCRAM 同样是 SASL 框架下的一种身份验证机制，它的核心思想与 DIGEST-MD5 相似，同样是应用一次性的随机数要求客户端生成响应，所以客户端同样无需在网络上传输明文明码。但与 DIGEST-MD5 不同的是，SCRAM 引入了盐值（Salt）和迭代次数（Iterations），并且应用了 SHA-256、SHA-512 这些更平安的哈希算法，这带来了更高的安全性，使 SCRAM 可能更加平安地存储明码，并且缩小被离线攻打、重放攻打或其余攻打破解的危险。 ...

引言如果您从事物联网相干的工作，或者有实时数据传输的我的项目教训，那么您可能对 MQTT (Message Queuing Telemetry Transport) 曾经有所理解。MQTT 是一种轻量级的、基于公布-订阅模式的网络协议，它负责设施之间的音讯通信，是物联网中不可或缺的一部分。 本系列文章将探讨 MQTT 中对于大规模物联网部署至关重要的一个问题：MQTT Broker 集群。 咱们心愿通过本系列文章全面摸索以后的 MQTT 技术，提供有价值的见解，引发有意义的探讨，帮忙您的 MQTT 和物联网之旅中激发翻新灵感。 什么是 MQTT Broker 与集群？在 MQTT 的公布-订阅 模型中，MQTT Broker 是一个要害组件，它负责解决发布者和订阅者之间的音讯传输。 咱们能够把 Broker 比作一个邮局，它接管来自各种发送者的音讯，对它们进行分类，并确保它们送达正确的收件人。 在 MQTT 中，发布者将音讯（例如传感器数据或命令）发送到 Broker，而后 Broker 依照主题对这些音讯进行归类。订阅者依据本人的趣味订阅某些主题，并从 Broker 接管这些主题下的音讯。这种机制让 MQTT 可能高效地解决实时数据，使其成为物联网利用的首选协定。 MQTT Broker 集群，简略来说，就是一组协同工作的 MQTT Broker，独特保障服务的连续性和可用性。如果某个 Broker 呈现故障，集群中的其余 Broker 会顶上来，保障服务不中断。因而，集群对于那些不能接受停机的企业和服务来说十分重要。 为什么要应用 MQTT Broker 集群？如果您有数以千计甚至百万计的物联网设施连贯到单个 MQTT Broker，而它忽然解体或者不可用了，所有设施都失去连贯，数据流中断，这将会造成重大损失。通过 Broker 集群，能够扩散负载，升高这种劫难的危险，并保障将来的扩展性。 从宏观角度来看，以下是 MQTT Broker 集群的劣势。 可扩展性：MQTT Broker 集群的一个要害劣势是它可能轻松地扩大以适应增长。随着物联网网络中连贯设施的数量或数据量的一直减少，您能够向集群增加 Broker 来解决更多的负载。这使得零碎可能顺畅高效地扩大，而不会给单个 Broker 带来过重的累赘或影响零碎性能。高可用性：高可用性对于须要解决继续数据流的物联网利用十分重要。在集群化的环境中，如果单个 Broker 呈现故障，集群中的其它 Broker 会持续运行，保障服务不间断。这种冗余升高了单点故障的危险，为物联网设施提供了一个更持重和牢靠的网络环境。负载平衡：借助 DNS 解析或负载均衡器，能够在集群所有 Broker 之间平均调配负载。这样能够避免单个 Broker 成为性能瓶颈。通过共享负载，每个 Broker 都能够高效地运行，从而晋升整体性能和响应速度。这特地有利于音讯量大或连贯设施多的场景。集中管理：集群容许对 Broker 进行集中化治理，简化治理工作。不须要一一解决每个 Broker，能够从单点对整个集群进行更改，节省时间并缩小出错。这种集中式办法也提供了零碎性能的全面视图，有助于监控、调试和优化网络性能。保护灵便：如果只有一个 Broker，停机保护可能会导致服务中断。有了集群，您能够在不影响整体服务的状况下对单个节点进行保护或降级。本系列文章将探讨的内容咱们心愿通过本系列文章和您一起深刻摸索 MQTT Broker 集群，从基本概念到高级实现，独特探讨和增进对这些技术的了解。 ...

引言在过来十年里，MQTT 协定在物联网畛域取得了宽泛的利用。很多物联网服务提供商都须要灵便可扩大的 MQTT 服务，采纳多租户架构的 MQTT 则为他们提供了一种新的抉择。 本文将探讨 MQTT 多租户架构以及其为用户带来的劣势和挑战。 什么是多租户架构？多租户（Multi-tenancy ）是一种软件架构模式，它能让利用的单个实例同时为多个租户（用户或客户）提供服务，每个租户都领有本人独立的数据和配置。 在这种架构下，多个租户共用同一套基础设施、数据库和集群，但每个租户只能拜访属于本人的数据和配置。这意味着租户能够依据本人的需要定制服务，而不会影响其余租户的数据或配置。同时，提供商也能够通过在同一套基础设施上为多个租户提供服务来降低成本。 对于 MQTT Broker 而言，多租户架构是一种高效且经济的解决方案，能够同时为多个客户或团队提供 MQTT 服务。 MQTT 中的多租户架构：实现每个租户的数据隔离MQTT Broker 多租户架构的外围是数据隔离。这样能够确保每个租户都将本人视为整个集群的惟一用户，他们不能拜访其余租户的客户端，更不能与其余租户的客户端互动。它包含以下五个次要方面： 无需对客户端限度。客户端能够应用任意客户端 ID、用户名和明码，不受其余租户的影响。甚至不同的租户能够应用雷同的客户端 ID 同时接入。认证/受权数据隔离。每个租户都有本人独立的认证和受权数据，用于管制客户端登录和主题的公布/订阅权限。租户只能操作本人的数据，而且这些数据只对该租户的客户端失效。音讯隔离。不同租户的客户端不能互相通信。只管租户能够应用任意主题，包含其余租户应用的主题，然而音讯依然齐全隔离。独立的用户层接口。包含治理网站和 HTTP API。租户只能治理和查看本人的数据，不能批改其余租户的数据。差异化配置。应该为每个租户提供独立的配置，以满足他们特定的资源和性能需要。MQTT 多租户架构的劣势和挑战MQTT 多租户架构为物联网解决方案提供商带来了双重劣势： 灵活性：MQTT 多租户架构比专有架构更加灵便。这次要体现在两个方面：一是它无需为每个租户独自搭建基础设施，能够疾速提供 MQTT 服务。二是它能够在不中断服务、不重新分配底层基础设施的状况下，为单个租户量身定做免费套餐。节省成本：MQTT 多租户架构是专用架构的低成本代替计划，能够让多个租户共享同一套基础设施。相同，专用架构要求每个租户都有本人的基础设施，这在建设和保护方面会带来高额的老本。但同时，采纳 MQTT 多租户架构也存在一些挑战： 保障正确隔离租户数据。在任何状况下，租户都不能拜访或治理其余租户的设施和数据。因而，必须采取严格的安全措施，包含紧密的拜访控制策略、正当的认证和受权机制、以及基于角色的访问控制。必要时采纳数据加密来确保数据在传输过程中的平安。无效治理资源竞争。因为多个租户共享同一套基础设施，例如网络带宽、CPU 或内存等，租户之间必然存在资源竞争的状况。关键在于零碎必须可能限度租户对资源的应用，以防止某资源被某个租户齐全耗尽，而影响到其余租户的失常应用。通常状况下，咱们能够通过为每个租户设置配额和速率限度策略来管制资源的耗费。例如，能够为租户设定最大连接数和订阅数的限度，以及音讯速率的限度。一旦达到限度，服务能够拒绝请求，以避免租户对资源的适度耗费。EMQX Cloud Serverless：基于多租户架构的 MQTT 服务EMQ 基于翻新的多租户技术推出了一种 Serverless MQTT 服务 - EMQX Cloud Serverless。EMQX Cloud Serverless 能够让用户在几秒内疾速部署 MQTT 服务，无需放心服务器基础设施治理或服务扩大时的资源分配问题。它还提供了每月 100 万分钟的永恒收费额度，采纳即用即付的免费模式，极大地升高了物联网老本。 结语随着物联网设施一直增长，新利用场景不断涌现，MQTT 多租户架构在将来的物联网市场有着广大的前景。采纳这种架构，岂但能够为客户提供更灵便的 MQTT Broker 服务，还能够在大规模部署时为客户升高经营老本。 版权申明： 本文为 EMQ 原创，转载请注明出处。 原文链接：https://www.emqx.com/zh/blog/multi-tenancy-architecture-in-mqtt

引言在物联网畛域，存在大量资源受限的传感器和工业管制设施运行在低带宽且不稳固的网络环境中，这使得 MQTT 成为物联网场景下现实的音讯传输协定。因而，MQTT Broker 必须保障优异的性能和高度的可靠性，以满足物联网利用的要求。 在进行零碎测试之前，理解根本的测试场景和性能指标至关重要。在本文中，咱们将依据 EMQX 团队的测试教训提供一份详尽的阐明，它也同样实用于其余 MQTT Broker 测试。 名词解释 MQTT 协定：MQTT（Message Queuing Telemetry Transport）是一种基于公布/订阅模式的轻量级音讯传输协定。只管其名称中蕴含"音讯队列"一词，但它与音讯队列并无关联。该协定因其简洁、灵便、易于实现、反对 QoS 以及音讯体积小等特点而成为物联网畛域的首选协定。 性能测试：性能测试是指利用测试工具模仿各种失常、峰值或异样负载条件，以评估被测试零碎在各种性能指标上的体现。其目标在于验证零碎是否可能满足用户的冀望，并发现零碎中存在的性能瓶颈和问题。 常见的 MQTT 测试场景MQTT Broker 次要有两种测试场景： 并发连贯，包含并发连接数和连贯速率。音讯吞吐，包含音讯发送和接管的吞吐量，以及一些影响生产环境零碎性能的因素，如 QoS、有效载荷大小、主题通配符等。在设计具体的性能测试场景时，特地是在进行 PoC 或部署前测试时，必须始终留神以下两点： 尽量模仿实在生产环境中的应用状况。笼罩可能的峰值负载。测试场景能够依照连贯和音讯吞吐量两个根本维度进行划分。 并发连贯测试MQTT 连贯是一种基于 TCP 的长连贯。客户端首先与 MQTT Broker 建设 TCP 连贯，而后发送 MQTT 登录申请。连贯胜利建设后，客户端和 MQTT Broker 通过定期发送心跳包来维持连贯状态。所以建设和长期维持一个MQTT连贯是须要占用MQTT broker肯定资源的，在高并发场景下，这种长连贯会耗费 Broker 的大量资源。因而，通过性能测试，咱们能够评估 MQTT Broker 在无限资源下可能接受多少并发连贯。 另外，连贯速率（即每秒新增连接数）越高，须要的计算资源越多，在制订测试场景时须要思考这个因素，因为在有些场景下大量的设施会同时上线，在测试broker的能力或规划系统容量时须要这个指标。 在并发连贯测试中还要思考是否应用 TLS/SSL 加密传输，因为它会减少压力机和MQTT Broker额定的资源开销。在打算测试时，须要评估它对性能的影响。 综上所述，在 MQTT 并发连贯测试中，应该思考以下三种场景： 在固定的较低连贯速率下逐步提高并发连接数，测试零碎响应和资源耗费状况。这能够确定零碎在给定的硬件和网络资源下可能接受的最大并发数。在给定的并发连接数下，测试不同连贯速率下零碎的响应和资源耗费状况。在设计 1) 和 2) 时，辨别一般 TCP 连贯和 TLS/SSL 加密连贯。音讯吞吐量测试如前文所述，MQTT 是一种基于公布/订阅模式的音讯传输协定，它是一种异步协定，实现了公布-订阅 1对1，1对多，多对1这3种类型，广泛应用于各种物联网场景。因而，音讯吞吐量测试应该涵盖以下三种场景： ...

本文是 MQTT 协定的入门指南，提供了实用的代码示例。物联网和 MQTT 的初学者能够通过本文把握 MQTT 的基本概念，疾速开启 MQTT 服务和利用的开发。 什么是 MQTT？MQTT（Message 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 协定凭借其轻量级、公布/订阅模型和可靠性，曾经成为构建物联网平台的首选计划。然而，随着业务的增长，物联网解决方案提供商可能面临基础设施维护费用回升和数据隐衷要求进步的挑战。 开源 MQTT 音讯平台的领导者 EMQ 近日推出了 EMQX Cloud BYOC，容许用户在自选的云环境中部署 MQTT 集群，从而齐全掌控数据隐衷和平安。 本文将对 BYOC 模式和 EMQX Cloud BYOC 的架构进行具体介绍，帮忙您全面理解它如何助力您的业务。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1236106?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

引言咱们很快乐地发表：由 EMQ 提供的 MQTT 凋谢基准测试标准现已正式公布！该测试标准蕴含了实用的典型应用场景、一套掂量 Broker 性能的次要指标，以及一个模仿负载和收集测试后果的工具，能够帮忙开发者评估 MQTT Broker 的可扩展性和性能，从而抉择最须要和适合的产品。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1197886?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

引言EMQX 和 NanoMQ 都是由寰球当先的开源物联网数据基础设施软件供应商 EMQ 开发的开源 MQTT Broker。 EMQX 是一个高度可扩大的大规模分布式 MQTT Broker，可能将百万级的物联网设施连贯到云端。NanoMQ 则是专为物联网边缘场景设计的轻量级 Broker。 本文中咱们将对 EMQX 和 NanoMQ 这两个 Broker 进行具体的比照剖析。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1194353?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

认证是一种安全措施，用于辨认用户并验证他们是否有权拜访零碎或服务器。它可能爱护零碎免受未经受权的拜访，确保只有通过验证的用户能力应用零碎。物联网连贯万物，对试图拜访基础设施的用户进行认证至关重要。未经受权的拜访存在重大的安全隐患，必须加以防备。因而，物联网开发者应该全面理解各类认证办法。 在本文中，咱们将探讨 MQTT 中的认证机制，以及其能够解决什么平安危险，并介绍一种罕用的认证形式：基于明码的认证。 MQTT 中的认证在 MQTT 中，认证是在连贯建设时对客户端或者服务端的身份进行验证的过程。它仅波及是否有权限连贯到 Broker，与受权不同，后者决定客户端能够公布和订阅哪些主题。咱们将在本系列之后的文章中对受权进行具体解说。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1194272?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

MQTT Broker 是用于连贯物联网设施，实现消息传递的重要组件。MQTT Broker 的选型，是物联网利用构建过程中最为根底也是最为要害的一步。本文将从物联网利用广泛场景和我的项目需要登程，提供一些通用的选型思路和关注点，帮忙读者理解如何抉择一款最适宜本人的 MQTT Broker。 明确您的我的项目需要目前市面上可供选择的 MQTT Broker 多达数十种，其中既有反对公有部署的 MQTT Broker，也有提供 MQTT 接入的云服务。 数量繁多的 MQTT Broker 在给您的抉择带来更多灵活性的同时，也减少了抉择的难度。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1191871?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

前言随着物联网技术的迅猛发展，人与设施、设施与设施之间的互动已变得不再艰难，而如何更加天然、高效、智能地实现交互则成为物联网畛域新的挑战。 近期，由 OpenAI 公布的 ChatGPT、GPT-3.5 和 GPT-4 等先进大语言模型（LLM）及其利用在寰球范畴内迅速遍及，为通用人工智能（AGI，Artificial General Intelligence）与物联网畛域的联合带来了更多可能性。 作为一款先进的自然语言解决利用，ChatGPT 凭借其卓越的自然语言解决能力可轻松实现人与机器的天然对话。而物联网畛域的支流协定 MQTT（Message Queuing Telemetry Transport）通过轻量级、低带宽占用的通信形式以及公布/订阅模型，保障了数据的实时传输与高效解决。 咱们由此能够大胆构想，将 MQTT 协定与 ChatGPT 联合应用，能够更加轻松地实现物联网畛域的人机智能交互： 在智能家居畛域，用户能够通过与 ChatGPT 天然对话来管制家中的智能设施，进步生活品质。在工业自动化畛域，ChatGPT 能够帮忙工程师更疾速地剖析设施数据，进步生产效率。…基于此，本文将探讨如何将 MQTT 协定与 ChatGPT 这样的自然语言解决利用相结合，同时将通过一个简略的搭建示例来展现联合后的利用场景，为读者摸索物联网智能利用提供一些思路。 根底概念在开始前，咱们须要先简略理解对于 MQTT 与 ChatGPT 的一些基本概念。 MQTT 协定如上文所提，MQTT 协定是一种基于公布/订阅模式的轻量级音讯传输协定，目前曾经广泛应用于物联网、挪动互联网、智能硬件、车联网、智慧城市、近程医疗、电力、石油与能源等畛域。 应用 MQTT 协定连贯海量物联网设施须要 MQTT 服务器这一要害组件。下文的方案设计中咱们将采纳大规模分布式物联网 MQTT 音讯服务器 EMQX，实现海量物联网设施的高效牢靠连贯以及音讯与事件流数据的实时处理散发。 之后，咱们就能够应用 MQTT 客户端来连贯 MQTT 服务器，实现与物联网设施的通信。本文中采纳的是开源的跨平台 MQTT 客户端 MQTTX，它蕴含桌面、命令行和 Web 端的利用，能够轻松实现与 MQTT 服务器的连贯测试，帮忙开发者疾速开发和调试 MQTT 服务及利用。 ChatGPTChatGPT 是一款自然语言解决利用，它基于 OpenAI 的 GPT-3.5 和 GPT-4 等先进大语言模型构建。GPT（Generative Pre-trained Transformer）是一种深度学习模型，以其弱小的文本生成和理解能力而闻名。ChatGPT 可能了解和生成自然语言，与用户进行晦涩、天然的对话。而要实现 ChatGPT 的自然语言解决能力，咱们就须要应用 OpenAI 提供的 API 来与 GPT 模型进行交互。 ...

本文介绍在MQTT客户端代码实现过程中，主动重连逻辑设计的重要性与示例，帮忙读者设计更为正当的重连代码，构建更加稳固牢靠的物联网设施连贯。 背景MQTT 是一个基于 TCP 协定的公布/订阅模型协定，它被广泛应用于物联网、传感器网络和其余低带宽、不稳固网络环境中。在这些网络环境中，网络连接往往不稳固，可能会呈现网络故障、信号弱化、丢包等问题，这可能会导致 MQTT 客户端与服务器之间的连贯中断。物联网利用中，常见的触发断线重连的场景包含： 网络环境恶劣或者断网，造成 MQTT 客户端连贯超时断开。因为业务须要服务端降级切换，服务端被动敞开断开。残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1181817?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

引言规定引擎是一种可能依据输出数据依照预设规定进行决策或执行动作的软件系统。本文将向您介绍 EMQX MQTT Broker 的规定引擎性能，并论述其在 MQTT 音讯转换和数据集成方面的重要作用。同时，咱们还将提供一份疾速入门指南，通过实例帮忙您疾速上手 MQTT 规定引擎。 MQTT 的规定引擎是什么？MQTT 是一种高效牢靠的音讯传输协定，特地实用于低带宽、高提早网络（在物联网畛域非常常见）。在 MQTT 的公布/订阅模型中，MQTT Broker 扮演着要害角色，负责接管发布者发送的音讯并将其牢靠高效地分发给订阅者，确保音讯的顺利传递。 MQTT 规定引擎是一种能够针对 MQTT 音讯制订和执行规定的组件。该规定引擎具备提取、过滤、加工和转换 MQTT 音讯的能力，并且能够在满足特定条件时触发相应的动作。通过规定引擎的利用，能够缩小人工干预，进步数据集成和利用开发的效率。 MQTT Broker 中规定引擎的利用场景规定引擎在 MQTT Broker 中有着宽泛的利用，能够实现工作自动化、系统监控、效率晋升和平安保障。例如： 在智能家居自动化中，规定引擎能够实现一些工作的自动化，比方依据人员进出房间的状况自动开关灯，或者依据不同时间段调节室温。既能够节省能源，也能够让居住者享受更加便捷的生存体验。在工业物联网利用中，它能够监控和管制简单的零碎，比方制作流程或电网。通过制订相应的规定，规定引擎能够发现和解决异样，从而防止设施故障，进步零碎性能。在医疗保健行业中，它能够监测患者的衰弱状态，并及时向医护人员报告可能存在的问题，帮忙医护人员更好地关注患者的健康状况，及时采取必要的医治措施，进步医疗保健的成果和品质。EMQX 开箱即用的内置规定引擎EMQX 是一个开源、高度可扩大的 MQTT Broker，内置了规定引擎组件。它让用户能够用低代码的形式疾速构建数据处理的业务逻辑，从而升高了软件架构的复杂度。 咱们抉择在 Broker 外部嵌入规定引擎性能，而不是依赖 Broker 内部的独立的规定引擎，有两个起因： 首先，Broker 外部的规定引擎能够实现更高效和晦涩的通信。规定引擎能够间接获取 MQTT 音讯，无需额定的通信渠道或协定，这升高了提早，晋升了零碎性能。其次，这能够让整个零碎的部署和治理更加简略。将规定引擎和 Broker 作为对立的组件部署在一起，无需别离进行集成和治理，从而简化了部署过程，缩小了零碎复杂度。规定引擎疾速入门这里咱们将以 EMQX Enterprise 为例，以便应用企业版提供的各种数据集成动作和资源。 下载 EMQX Enterprise依据您的操作系统类型，在这里下载 EMQX Enterprise。在下拉列表中抉择最新版的 EMQX Enterprise 4.4： EMQX Enterprise 的默认许可证反对最多 10 个 MQTT 连贯，对于咱们体验规定引擎的性能来说曾经足够了。如果您须要更多的 MQTT 连贯，请点击“下载”按钮下方的链接申请 15 天收费试用。 这里咱们以 Ubuntu 20.04 为例，下载 EMQX Enterprise 4.4.17 安装包： ...

MQTT 最后作为一种轻量级的公布/订阅消息传递协定而设计，现在曾经成为工业物联网（IIoT）和工业 4.0 倒退的重要根底。它的意义在于实现了各类工业设施与云端的无缝连贯，促成了经营技术（OT）和信息技术（IT）的交融。 本文比照剖析了 2023 年工业物联网畛域最优良的三款 MQTT Broker，介绍了它们的长处、毛病和利用场景。同时，还展现了如何利用这三款 MQTT Broker，为您的工业物联网解决方案打造对立命名空间（UNS）架构。 我的项目概览本文选取的开源 MQTT Broker 次要基于以下两个规范： 开源我的项目的社区规模、受欢迎水平和我的项目活跃度。与资源受限的工业设施和网关的兼容性。基于此，咱们选出了三款最热门的开源 MQTT Broker： EMQX：GitHub 上 Star 数最多的 MQTT Broker，领有 11.6k Stars。EMQX 在启动时的内存占用约为 50M，反对集群性能。Mosquitto：Star 数位居第二然而应用最为宽泛的 MQTT Broker。它采纳单线程架构，在启动时的内存占用不到 1M。NanoMQ：目前最新且最沉闷的 MQTT Broker 之一。它反对多线程和异步 IO，在启动时的内存占用约为2M。以下是这三个我的项目在 GitHub 上的相干详情： EMQXMosquittoNanoMQOfficial WebsiteEMQXEclipse MosquittoNanoMQGitHub ProjectEMQX GitHubMosquitto GitHubNanoMQ GitHubProject Created201220092020LicenseApache License 2.0EPL/EDL LicenseMIT LicenseProgramming LanguageErlangC/C++CLatest Releasev5.0.23 (April 2023)2.0.15 (Aug 2022)v0.17.0 (March 2023)GitHub Stars11.5k7.2k800+GitHub Releases260+60+75+GitHub Commits14k+2800+2000+GitHub Commits (Last 12 Months)3000+500+1200+GitHub PRs6000+600780+GitHub Contributors100+110+20+1. EMQXEMQX 是一款高度可扩大的分布式 MQTT Broker，实用于企业级的工业物联网部署。它反对 MQTT 5.0、MQTT-SN、SSL/TLS、MQTT over QUIC 等多种协定。它通过 masterless 集群形式实现了高可用性和程度扩展性。 ...

引言MQTT 是一种轻量级的消息传递协定，实用于物联网利用实现设施间通信。 作为一款支流的开源 MQTT Broker，EMQX 可能提供高扩展性、可靠性和安全性的 MQTT 消息传递服务。 借助广泛应用的基础设施即代码（IaC）工具 Terraform，您能够轻松在 GCP 上主动部署 EMQX MQTT Broker，从而简化和标准 MQTT 基础设施的设置和治理。 本文将领导您如何设置 GCP 我的项目、创立服务账户、编写 Terraform 配置文件，实现轻松部署 EMQX MQTT Broker。 筹备工作在开始之前，请做好以下筹备： 注册 Google Cloud Platform 账户在您的本地机器上装置 Google Cloud SDK在您的本地机器上装置 Terraform对 GCP、Terraform 和 MQTT 有根本的理解配置 GCP 环境依照以下步骤配置 GCP 环境： 创立新的 GCP 我的项目或应用已有的我的项目（Project）。为您的我的项目启用所需的 API（Compute Engine API）。为 Terraform 创立具备所需权限的服务账户。倡议应用 Compute Engine Admin 角色。下载 JSON 密钥文件。应用 Terraform 在 GCP 上部署 EMQX配置 Terraform在您的 Terraform 代码中配置 GCP Provider，并应用服务账户密钥文件进行认证。 provider "google" { credentials = file("<PATH-TO-KEY-FILE>") project     = "<PROJECT-ID>" region     = "<REGION>" zone       = "<ZONE>"}配置网络这一步须要理解 GCP 相干的三个根本术语：我的项目、VPC 和子网（Subnet）。这些术语的定义如下： ...

mqtt 协定

引言您是否心愿将物联网基础设施晋升到更高的程度？为了应答业务的一直扩大，您须要一个弱小且平安的音讯平台来反对它。 MQTT 协定凭借其轻量级、公布/订阅模型和可靠性，曾经成为构建物联网平台的首选计划。然而，随着业务的增长，物联网解决方案提供商可能面临基础设施维护费用回升和数据隐衷要求进步的挑战。 开源 MQTT 音讯平台的领导者 EMQ 近日推出了 EMQX Cloud BYOC，容许用户在自选的云环境中部署 MQTT 集群，从而齐全掌控数据隐衷和平安。 本文将对 BYOC 模式和 EMQX Cloud BYOC 的架构进行具体介绍，帮忙您全面理解它如何助力您的业务。 什么是 BYOCBYOC（Bring Your Own Cloud）是一种让您能够在自选的私有云环境（如阿里云、华为云、亚马逊云等）部署 MQTT 集群并交由业余团队托管的服务模式。它让您能够齐全掌控云基础设施，并可能满足严格的数据合规要求。 服务模式：只需为您应用的服务付费EMQX Cloud BYOC 采纳云原生架构，重视扩展性、可用性和安全性，提供 99.99% 服务等级协定（SLA）的高可用 MQTT 服务。 基于订阅的许可证模式使您可能依据须要灵便扩大 MQTT 基础设施。得益于对云平台上资源管理的便利性和 BYOC 托管服务，您无需提前投入人力和物力，只需为应用的服务付费。 订阅的服务中还涵盖基于 Prometheus、Grafana、Open Telemetry 等云原生工具的 7x24 小时技术支持和保护服务，让您的 MQTT 基础设施始终保持稳定，取得及时更新。 架构：保障高级别的数据隐衷EMQX Cloud BYOC 架构由 EMQX Cloud 云环境和客户的云环境两局部组成，它们的构建形式如下图所示。 在客户本人的云环境中，有一个 EMQX 集群和一个 BYOC Agent 节点，它们位于一个独立的 VPC 内。您能够应用云平台提供的负载平衡服务（例如阿里云 SLB）来管制 MQTT 设施的流量，同时通过 VPC 对等连贯与其余物联网利用或音讯长久化组件进行通信。BYOC Agent 节点负责管理 EMQX 集群、获取监控日志、执行数据备份。 ...

前言：最近小编在折腾Arduino，为了让板子联网又买了ESP8266 NODEMCU (wifi模块，也是一个单片机)。尽管能通过烧录的程序通过http申请本人的服务器接口，然而显然并不合乎当下支流的物联网形式，并且定时申请接口还浪费资源。      于是就引出了MQTT协定，在网上我也找了对于MQTT代理服务的软件也有很多。比方Eclipse基金会的Mosquitto ，以及Apache的 Apollo，当然还有很多次要看本人的需要，而我抉择了国内的EMQ。  MQTT简介：MQTT(Message Queuing Telemetry Transport，音讯队列遥测传输)是IBM开发的一个即时通讯协定，有可能成为物联网的重要组成部分。该协定反对所有平台，简直能够把所有联网物品和内部连接起来，被用来当做传感器和制动器(比方通过Twitter让屋宇联网)的通信协议。  EMQ简介：EMQ X Enterprise 企业级物联网 MQTT 音讯平台，反对百万级物联网设施一站式接入、MQTT&CoAP 多协定解决、低时延实时音讯通信。反对基于 SQL 的内置规定引擎，灵活处理/转发音讯到后端服务，存储音讯数据到各种数据库，或桥接 Kafka、RabbitMQ 等企业中间件。  实现思路：应用EMQ搭建MQTT的代理服务器。后盾(PHP)能够通过phpMQTT类库或者通过装置扩大作为客户端连贯mqtt代理，公布音讯或订阅主题，和将音讯存入数据库等等。硬件Esp8266 NodeMCU通过mqtt库连贯代理，同样的公布音讯或者订阅主题。 搭建过程：EMQ官网点击下载，产品->EMQ X Broker->下载。 依据本人零碎，抉择下载。 解压缩之后，失去上面目录 命令面板进入该目录，执行emq start。 浏览器关上 http://localhost:18083就能够进入EMQ的web控制台了。 EMQ管控后盾默认账号: admin 明码: public，如果遗记了也能够在装置目录的etc\plugins的emqx_auth_username.conf，关上文件能够看到账号密码了。 代理服务曾经创立，接下来就能够通过mqtt客户端连贯测试一下，这里的客户端举荐EMQ的在线客户端，这里小编就安利一款国外的客户端 “MQTT.fx”的软件，能够在网上搜寻下载，接下来也以这个举例。 创立一个MQTT代理服务器，就是刚刚本地启动的，输出以下相似地址。 点击connect就马上连贯，当左边圆点是绿色示意连贯胜利，接下来就能够测试一下订阅和公布了。 订阅一个主题，名称能够本人随便定义。 在对应主题下公布一条音讯，就是刚刚创立的，而后内容轻易填写，点击订阅就能够看到该主题的音讯了。 EQM代理后盾也能够看到刚刚公布订阅与连贯信息了。 ESP8266 NODEMCU连贯代理服务，也能够订阅指定的主题，公布或接管音讯实现硬件的操作。比方管制LED开关，给另一主题发送板子的温度音讯等等。 其余：EMQ的端口枚举如下： 本地敞开MQTT服务, 进入软件目录命令输出emqx stop启动mqtt服务后，能够依据端口查看过程，而后依据过程号敞开该服务。

近日，EMQ 旗下的工业协定网关软件 Neuron 公布了最新的 2.4.0 版本。 该版本新增了包含 ABB COMLI 在内的四个南向驱动和一个北向利用，同时对现有的插件性能和 UI 进行了优化。 疾速体验 Neuron 新版本新增驱动插件满足不同场景需要IEC61850 MMS 和 Allen-Bradley DF1IEC61850 MMS 这一广泛应用于电力行业的通信协议现已集成到 Neuron 中，用户能够利用 Neuron 更加流畅地与应用该协定的工业设施进行通信。此外，Neuron 2.4.0 还新增了 Allen-Bradley DF1 驱动插件，为用户提供了另一种连贯 Allen-Bradley PLC 的抉择。 HJ212-2007 和 ABB COMLIHJ212-2007 是中国环境空气质量监测的国家标准，ABB COMLI 则是用于工业自动化零碎（如机器人、电力和自动化）中设施之间通信的协定。这些驱动插件进一步扩大了 Neuron 的连贯能力，使得 Neuron 能够与更加多样化的工业设施实现通信。 WebSocket 利用Neuron 2.4.0 版本中还引入一个新的北向利用 WebSocket，用于设施和 Neuron 之间的实时通信，提供更快的响应工夫，实用于要害基础设施的监控和管制。 优化现有插件性能新版本也对现有性能进行了诸多优化： 加强现有驱动插件能力：IEC60850-5-104 协定驱动当初反对遥测和时钟同步，为用户提供更弱小的设施同步控制能力。MQTT 提供可配置的 QoS 和自定义主题订阅以进行组订阅，进一步减少了协定的灵活性。监控插件反对实时配置更改事件报告：容许用户实时监督其配置的变动，提供更强的工业设施可见性，确保用户能够疾速无效地响应问题。在不同机器上连贯 eKuiper：当初用户能够在不同的机器上部署 Neuron 和边缘流式计算引擎 eKuiper，实现高效、定制化的工业物联网环境设置。通过新的读写存储点加强数据灵活性：新的存储点可读可写，提供更大的灵活性，用户能够更轻松地治理和定制其工业物联网环境，以满足其特定需要。API 和 UI 晋升Neuron 2.4.0 版本还装备了新的 API 以加强对工业物联网环境的治理。这些 API 提供的能力包含：获取和替换全局配置、文件下载、监控零碎 CPU、内存和磁盘应用状况等。新的 API 为用户确保最佳性能和及时监测问题提供了无力工具。 ...

一个MQTT客户端能够做到：1、公布其余客户端可能会订阅的信息2、订阅其它客户端公布的音讯3、退订或删除应用程序的音讯4、断开与服务器连贯 所以在应用Java代码进行搭建时，也要实现这几种性能。 MQTT客户端（发布者）1、创立一个SendMQTT类，对MQTT客户端进行初始化操作，创立连贯。 public class SendMqtt { public static MqttClient mqttClient = null; private static MemoryPersistence memoryPersistence = null; private static MqttConnectOptions mqttConnectOptions = null; static { init("happyfan"); } public static void init(String clientId) { //初始化连贯设置对象 mqttConnectOptions = new MqttConnectOptions(); //初始化MqttClient if(null != mqttConnectOptions) {// true能够平安地应用内存持久性作为客户端断开连接时革除的所有状态 mqttConnectOptions.setCleanSession(true);// 设置连贯超时 mqttConnectOptions.setConnectionTimeout(30);// 设置长久化形式 memoryPersistence = new MemoryPersistence(); if(null != memoryPersistence && null != clientId) { try { mqttClient = new MqttClient("tcp://127.0.0.1:1883", clientId,memoryPersistence); } catch (MqttException e) { // TODO Auto-generated catch block e.printStackTrace(); } }else { } }else { System.out.println("mqttConnectOptions对象为空"); } System.out.println(mqttClient.isConnected()); if(null != mqttClient) { if(!mqttClient.isConnected()) { try { System.out.println("创立连贯"); mqttClient.connect(mqttConnectOptions); } catch (MqttException e) { // TODO Auto-generated catch block e.printStackTrace(); } } }else { System.out.println("mqttClient为空"); } System.out.println(mqttClient.isConnected()); }}2、实现与MQTT客户端断开连接以及从新连贯的性能： ...

MQTT协定简介1、公布/订阅MQTT协定应用的是公布/订阅音讯模式。其中一个MQTT客户端订阅了某一个主题，期待MQTT服务器转发。假如又有一个MQTT客户端公布了无关这个主题的音讯，MQTT服务端就会在订阅的主题中寻找是否有客户端订阅了这个主题。如果有，MQTT服务端就会转发这个音讯到订阅了这个主题的MQTT客户端。 2、MQTT协定的实现形式实现MQTT协定须要MQTT客户端与MQTT服务端通信实现，在这个过程中，MQTT协定中有存在着三个角色：发布者、代理(MQTT服务端)、订阅者。其中，MQTT客户端既能够是发布者，也能够是订阅者，两者能够同时存在。MQTT传输的音讯分为：主题(Topic)和负载(payload)两局部。(1)Topic，能够了解为是钥匙和锁(订阅的主题是锁，公布的主题是钥匙)，如果订阅和公布的是同一个主题，订阅者就能够收到该主题的内容。(2)payload，是MQTT传输音讯的内容。 3、MQTT协定的三种音讯公布1、QoS0(至少一次)：音讯公布齐全依赖底层TCP/IP网络，如果此时MQTT客户端在音讯推送时没有连贯上MQTT服务端，就会导致音讯接管不到，时候连贯上也不会接管到数据。2、QoS1(至多一次)：确保音讯达到，但音讯反复可能会产生。3、QoS2(只有一次)：确保用户收到音讯而且只收到一次音讯。 4、MQTT客户端与服务端一个MQTT客户端能够做到：1、公布其余客户端可能会订阅的信息2、订阅其它客户端公布的音讯3、退订或删除应用程序的音讯4、断开与服务器连贯 一个MQTT服务端能够做到：1、承受来自客户的网络连接2、承受客户公布的利用信息3、解决来自客户端的订阅和退订申请4、向订阅的客户转发应用程序音讯 MQTT协定的利用接下来会通过EMQS官网提供的MQTT服务器与MQTT X官网提供的MQTT客户端实现一次简略的通信。EMQS官网：https://www.emqx.io/zh/downloads?os=WindowsMQTT X官网：https://mqttx.app/zh 1、在EMQX官网中下载Windows零碎的emqx。装置实现后，关上该文件，进入bin文件夹。关上终端，输出./emqx start如图所示，MQTT就开启胜利了，这时能够拜访官网提供的MQTT治理控制台(http://127.0.0.1:18083/)。默认的账号密码是：admin public。进入之后就能看到一些根本信息。 2、在MQTT X官网中下载开源的Windows版本的MQTTX，用于充当MQTT客户端。下载实现后，如图所示，创立一个连贯、主题：我这里创立了一个hello的主题，点击公布能够看到，MQTT客户端收回一条主题为hello,负载为Hello MQTT的音讯，而且MQTT客户端也接管到了来自MQTT服务端转发的音讯。如果不是同一个主题呢？能够看到，音讯尽管公布了，然而MQTT客户端并没有接管到hello1主题的音讯。 完结MQTT协定的简介以及简略利用到这里就完结了，下次实现Java代码搭建MQTT客户端，实现音讯的订阅/公布。

一、简介mica-mqtt 基于 java aio 实现的简略、低提早、高性能 的 mqtt 物联网开源组件。 mica-mqtt 更加易于集成到已有服务和二次开发，升高自研物联网平台开发成本。 二、性能反对 MQTT v3.1、v3.1.1 以及 v5.0 协定。反对 websocket mqtt 子协定（反对 mqtt.js）。反对 http rest api，http api 文档详见。反对 MQTT client 客户端。反对 MQTT server 服务端。反对 MQTT 遗嘱音讯。反对 MQTT 保留音讯。反对自定义音讯（mq）解决转发实现集群。MQTT 客户端 阿里云 mqtt 连贯 demo。反对 GraalVM 编译老本机可执行程序。反对 Spring boot 我的项目疾速接入（mica-mqtt-spring-boot-starter）。mica-mqtt-spring-boot-starter 反对对接 Prometheus + Grafana。基于 redis pub/sub 实现集群，详见 mica-mqtt-broker 模块。三、应用场景物联网（云端 mqtt broker）物联网（边缘端音讯通信）群组类 IM音讯推送简略、易用的 mqtt client 客户端四、更新记录v2.1.0 - 2023-03-05✨ 【不兼容】调整接口参数，方便使用✨ 【不兼容】底层重构调整✨ 兼容更多 Spring boot 版本，反对 2.1.0.RELEASE 以上版本。✨ ssl 反对双向认证 gitee #I61AHJ 感激 @DoubleH 反馈 修复遗嘱音讯判断 gitee #I6BRBV 感激 @tan90 反馈。 修复错别字 gitee #I6F2PA 感激 @hpz 反馈⬆️ 依赖降级五、迁徙指南mica-mqtt-core 拆分成了 mica-mqtt-client 和 mica-mqtt-server，防止一些依赖援用问题。HexUtil 由 net.dreamlu.iot.mqtt.core.util.HexUtil 挪动到了 org.tio.utils.mica.HexUtils。5.1 客户端5.1.1 订阅回调接口调整留神：mica-mqtt-client-spring-boot-starter 应用注解订阅能够直升。 ...

emqx开启自定义权限认证emqx broker装置 emqx 集群搭建 浏览器拜访WEB治理界面:http://127.0.0.1:18083/ 默认用户名和明码: admin/public 倡议批改 开启emqx_auth_http插件批改emq配置#批改emqx/etc/emqx.conf#禁用匿名认证 生产环境倡议禁用allow_anonymous = false#批改emqx/etc/plugins/emqx_auth_http.conf#配置连贯认证auth.http.auth_req.url = http://127.0.0.1:8080/isAuth.jsonauth.http.auth_req.method = postauth.http.auth_req.headers.content_type = application/jsonauth.http.auth_req.params = clientid=%c,username=%u,password=%P#超级用户auth.http.super_req.url = http://127.0.0.1:8080/isSuper.jsonauth.http.super_req.method = postauth.http.super_req.headers.content-type = application/jsonauth.http.super_req.params = clientid=%c,username=%u#权限认证auth.http.acl_req.url = http://127.0.0.1:8080/isPermission.jsonauth.http.acl_req.method = postauth.http.acl_req.headers.content-type = application/jsonauth.http.acl_req.params = access=%A,username=%u,clientid=%c,topic=%t#超时auth.http.timeout = 10sauth.http.connect_timeout = 10s#连接池auth.http.pool_size = 80

Linux装置mosquitto mqtt几种形式Eclipse Mosquitto是一个开源音讯代理，实现了MQTT协定版本3.1和3.1.1。提供轻量级的，反对可公布/可订阅的的音讯推送模式,Mosquitto的轻量，实用于低功耗单板计算机到残缺服务器的所有设施。Mosquitto我的项目还提供了用于实现MQTT客户端的C库以及十分受欢迎的mosquitto_pub和mosquitto_sub命令行MQTT客户端。 Linux离线装置mosquitto官网下载地址: https://mosquitto.org/download/ #下载包wget http://mosquitto.org/files/source/mosquitto-1.4.5.tar.gz#解压tar -zxvf mosquitto-1.4.5.tar.gz#进入目录,编译cd mosquitto-1.4.5/makesudo make install#拷贝配置cp mosquitto.conf /etc/mosquitto/#查看版本mosquitto -v#创立组和用户groupadd mosquittouseradd -g mosquitto mosquitto#查看服务启动ps -aux | grep mosquitto#启动服务mosquitto -c /etc/mosquitto/mosquitto.conf -d -v mosquitto-1.6.10版本的装置#解压mqtt包tar -zxvf mosquitto-1.6.10.tar.gzcd mosquitto-1.6.10/makesudo make install#拷贝配置cp mosquitto.conf /etc/mosquitto/#拷贝可执行文件cp /usr/local/sbin/mosquitto /usr/sbin/#查看帮忙mosquitto -h#创立分组和用户groupadd mosquittouseradd -g mosquitto mosquitto -s /sbin/nologin#查看启动状况ps -aux | grep mosquitto#mqtt启动文件复制指定目录cp mosquitto.service /etc/systemd/system/##增加文件执行权限chmod +x /etc/systemd/system/mosquitto.service#从新加载配置文件systemctl daemon-reload#设置mqtt开机自启systemctl enable mosquitto.service#查看mqtt开机启动状态systemctl is-enabled mosquitto.service#启动mqttsystemctl start mosquitto.service#查看启动状态systemctl status mosquitto.serviceps -aux | grep mosquittoCentOS在线装置mosquittoyum install -y mosquitomosquitto MQTT 高版本 2.x以上近程拜访设置mosquitto MQTT 高版本 2.x以上,默认是:只能本机拜访, 且不能匿名拜访减少:allow_anonymous true 容许匿名拜访listener 1883 能够近程拜访 ...

` // const MQTT_URL = "ws://192.168.50.221:8083/mqtt"; // const MQTT_PORT = 8083; const MQTT_TIMEOUT = 4000; // const MQTT_TOPIC = "device/field/update/CR-7iA/WS01_PL04_01/INP_CURRENT"; try { if(item.url?.length){ let url = new URL(item.url); let port = url.port; if(port?.length){ let c = mqtt.connect(`${item.url}`, { port: `${port}`, connectTimeout: MQTT_TIMEOUT, keepalive: 5, clientId: "mqtt_t_sub" + new Date().valueOf() }); c.on("connect", e => { console.info("========= SUBSCRIBER CONNECTED"); c.subscribe(`${item.topicUrl}`, {}, (err, granted) => { // console.info(err, granted); if (granted) { c.on("message", (topic, payload, packet) => { // console.info(">> " + payload.toString()); let stringData = payload.toString(),objData; if(stringData.includes('{') || stringData.includes('[')){ objData = JSON.parse(stringData); } else if(payload.buffer){ objData = new Int32Array(new Uint8Array(payload).buffer); } // console.info(">>JSON.parse(stringData) ", objData); _this.callbackFun(item, objData); }); } }); }); c.on("disconnect", e=>{ console.info("========= DISCONNECTED", e); }) c.on("error", e=>{ console.info("========= SUBSCRIBER ERROR...", e); }) } } } catch (e) { console.log(e); }`先上代码MQTT(websocket)类型 ...

一、简介mica-mqtt 基于 t-io 实现的简略、低提早、高性能 的 mqtt 物联网开源组件。 mica-mqtt 更加易于集成到已有服务和二次开发，升高自研物联网平台开发成本。 二、性能反对 MQTT v3.1、v3.1.1 以及 v5.0 协定。反对 websocket mqtt 子协定（反对 mqtt.js）。反对 http rest api，http api 文档详见。反对 MQTT client 客户端。反对 MQTT server 服务端。反对 MQTT 遗嘱音讯。反对 MQTT 保留音讯。反对自定义音讯（mq）解决转发实现集群。MQTT 客户端 阿里云 mqtt 连贯 demo。反对 GraalVM 编译老本机可执行程序。反对 Spring boot 我的项目疾速接入（mica-mqtt-spring-boot-starter）。mica-mqtt-spring-boot-starter 反对对接 Prometheus + Grafana。基于 redis pub/sub 实现集群，详见 mica-mqtt-broker 模块。三、应用场景物联网（云端 mqtt broker）物联网（边缘端音讯通信）群组类 IM音讯推送简略、易用的 mqtt client 客户端四、更新记录v1.2.10✨ mica-mqtt server 增加 MQTT 客户端 keepalive 系数 keepalive-backoff。✨ mica-mqtt client、server 调整公布的日志级别为 debug。✨ mica-mqtt client 优化 javadoc。✨ mica-mqtt client 重连时，反对从新设置新的鉴权账号和明码。v1.2.9✨ mqttServer#publishAll() 日志级别调整 gitee #I4W4IS✨ @MqttClientSubscribe 反对 springboot 配置 gitee #I4UOR3✨ mica-mqtt client 代码优化✨ mica-mqtt-spring-boot-example 拆分五、应用文档和示例mica-mqtt 应用文档mica-mqtt-spring-boot-starter 应用文档mica-mqtt http api 文档详见mica-mqtt 发行版本记录基于 redis 的 mqtt broker 集群示例基于 kafka 的 mqtt broker 集群示例

1、装置反对mqtt协定的emq，其中有两个版本emq和emqx官网连贯2、企业版本限度连贯数量为10个,装置命令docker pull emqx/emqx-ee 装置其余版本docker run -d --name emqx -p 18083:18083 -p 1883:1883 emqx/emqx-ee:latest客户端拜访门路 ip+18083 账号admin明码public3、emqx版本docker pull emqx/emqx:4.4.1装置其余版本docker run -d --name emqx -p 1883:1883 -p 8081:8081 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:4.4.1

遗嘱音讯是 MQTT 为那些可能呈现 意外断线 的设施提供的将 遗嘱 优雅地发送给第三方的能力。意外断线包含但不限于： 因网络故障或网络稳定，设施在放弃连贯周期内未能通信，连贯被服务端敞开设施意外掉电设施尝试进行不被容许的操作而被服务端敞开连贯，例如订阅本身权限以外的主题等遗嘱音讯能够看作是一个简化版的 PUBLISH 音讯，他也蕴含 Topic, Payload, QoS 等字段。遗嘱音讯会在设施与服务端连贯时，通过 CONNECT 报文指定，而后在设施意外断线时由服务端将该遗嘱音讯公布到连贯时指定的遗嘱主题（Will Topic）上。这也意味着服务端必须在回复 CONNACK 之前实现遗嘱音讯的存储，以确保之后任一时刻发生意外断线的状况，服务端都能保障遗嘱音讯被公布。 以下为遗嘱音讯在 MQTT 5.0 和 MQTT 3.1 & 3.1.1 的差别： MQTT 5.0MQTT 3.1 & 3.1.1Will RetainYesYesWill QoSYesYesWill FlagYesYesWill PropertiesYesNoWill TopicYesYesWill PayloadYesYesWill Retain、Will QoS、Will Topic 和 Will Payload 的用途与一般 PUBLISH 报文基本一致，这里不再赘述。 惟一值得一提的是 Will Retain 的应用场景，它是保留音讯与遗嘱音讯的联合。如果订阅该遗嘱主题（Will Topic）的客户端不能保障遗嘱音讯公布时在线，那么倡议为遗嘱音讯设置 Will Retain，防止订阅端错过遗嘱音讯。 Will Flag 通常是 MQTT 协定实现方关怀的字段，它用于标识 CONNECT 报文中是否会蕴含 Will Properties、Will Topic 等字段。 最初一个是 MQTT 5.0 新增的 Will Properties 字段，属性自身也是 MQTT 5.0 的一个新个性，不同类型的报文有着不同的属性，例如 CONNECT 报文有会话过期间隔（Session Expiry Interval）、最大报文长度（Maximum Packet Size）等属性，SUBSCRIBE 报文则有订阅标识符（Subscription Identifier）等属性。 ...

MQTT v5 相较于 MQTT v3.1 和 v3.1.1 提供了许多新个性。咱们会尽量以通俗易懂的形式展现这些个性，并探讨这些个性对开发者的影响。咱们曾经探讨过其中一部分 MQTT v5 新个性，明天将持续探讨：主题别名。 什么是主题别名主题别名（Topic Alias）是 MQTT v5.0 中新退出的与主题名（topic）相干的个性。它容许用户将主题长度较长且罕用的主题名缩减为一个双字节整数来升高公布音讯时的带宽耗费。 它是一个双字节整数，并将作为属性字段，编码在PUBLISH报文中可变报头局部。并且在理论利用中，将受到CONNECT报文和CONNACK报文中“主题别名最大长度”属性的限度。只有不超过该限度，任何主题名，都能够应用此个性缩减为编码长度2字节的整数。 为什么应用主题别名在应用 MQTT v3 协定时。如果客户端在某次连贯中须要公布大量雷同主题的音讯，那么在每一条PUBLISH报文中写入雷同的主题名，就造成了客户端和服务端之间带宽资源的节约。同时对于服务端而言，每次对雷同主题名的 UTF-8 字符串进行解析，都是对计算资源的节约。 构想这样的场景，在地位 A 以固定频率报告温度湿度的传感器： 应用 /position/A/temperature 作为该地位温度音讯的主题（长度23字节）；应用 /position/A/humidity 作为该地位湿度音讯的主题（长度20字节）。除去第一次公布音讯外，之后的每个PUBLISH报文，都须要将“主题名”这个曾经传递过的信息再次通过网络传输。即使抛开客户端和服务端之间额定的带宽耗费不言，对服务端来说，面对成千上万的传感器公布的大量音讯，对每个客户端的每条音讯，都要将同样的主题名字符串进行解析，这将造成了计算资源的节约。 此时应用 MQTT v5 中的主题别名个性，就能够无效升高资源耗费。当客户端或服务端公布频率较高，且主题名长度较大的情景下，应用主题别名能够将每条音讯中主题名的带宽耗费缩减为 2 字节，同时因为计算机解决整数的效率高于解决字符串的效率，对于客户端或服务端在报文解析时耗费的计算资源也有了肯定的节约。 怎么应用主题别名主题别名生命周期和作用范畴该值由客户端和服务端各自保护，且生命周期和作用范畴仅限于以后连贯。连贯断开后须要再次应用主题别名须要从新建设主题别名<=>主题名映射关系。 主题别名最大值（Topic Alias Maximum）在 MQTT 客户端和服务端应用主题别名进行公布音讯前，须要对能够应用的最大主题别名长度进行约定。这部份信息替换将在CONNECT报文和CONNACK报文中实现。“主题别名最大值”也将以报文属性的模式，用双字节整数值编码在CONNECT和CONNACK报文的可变报头中。客户端的CONNECT报文中"主题别名最大值"批示了本客户端在此次连贯中服务端能够应用的最大主题别名数量；同样地，服务端发送的CONNACK报文中，也通过此值表明了以后连贯中对端（客户端）能够应用的最大主题别名数量。 设置与应用主题别名客户端（或服务端）在发送PUBLISH报文时，能够在可变报头的属性局部，用一个字节，值为0x23的标识符批示接下来2字节将是主题别名值。 但主题别名值不容许为0，也不容许大于服务端（客户端）发送的CONNACK（CONNECT）报文中设置的主题别名最大值。 对端接管到带有主题别名值和非空主题名的PUBLISH报文后，将建设主题别名和主题名的映射关系，在此之后发送的PUBLISH报文中，便能够仅用长度2字节的主题别名公布音讯，对端将应用通过之前建设的主题别名<=>主题名映射关系来解决音讯中的主题。并且因为这一映射关系由双端各自保护，所以客户端与服务端能够应用值雷同的主题别名相互公布音讯。 应用未设置的主题别名PUBLISH报文中应用的主题别名值如果在此前的报文中未进行设置，即对端并未建设以后主题别名到某个主题名的映射关系，而此条报文的可变报头中主题名字段为空，对端将应用蕴含起因码（REASON_CODE）为0x82的DISCONNECT报文断开网络连接。 重置主题别名当对端曾经依据本次连贯中某个PUBLISH报文创立了一个主题别名<=>主题名的映射关系时，能够在下一次发送PUBLISH报文时应用同样的主题别名值和非空的主题名来更新这个主题别名值到主题名的映射关系。 总结主题别名作为 MQTT v5 新提供的个性，为 pub/sub 这一消息传递模型提供了更灵便的应用形式，对于主题名统一且数量大、重复性高的音讯而言，能够无效节俭带宽资源和计算资源。

近日，由 EMQ 开源的跨平台 MQTT 5.0 桌面测试客户端 MQTT X 公布了最新版本 v1.7.0。MQTT X 反对疾速创立多个同时在线的 MQTT 客户端，不便测试 MQTT/TCP、MQTT/TLS、MQTT/WebSocket 的连贯、公布、订阅性能及其他 MQTT 协定个性。 新公布的 1.7.0 版本对 MQTT 5.0 实现了更为全面的反对，是寰球目前为止对 MQTT 5.0 反对最为残缺的桌面测试客户端工具。同时新增了很多优化用户体验的性能。 在本文中，咱们将具体介绍 MQTT X v1.7.0 新增性能的具体应用操作，特地是如何应用 MQTT X 来测试 MQTT 5.0 的诸多个性，以便读者能够在理论我的项目中更好地利用 MQTT 5.0。 筹备 MQTT 音讯服务器在应用 MQTT X v1.7.0 对 MQTT 5.0 的个性进行测试之前，咱们首先须要筹备反对 MQTT 5.0 的 MQTT Broker。 本文将应用由 EMQ X Cloud 提供的收费在线 MQTT 5.0 服务器配合 MQTT X 客户端进行测试。作为一款全托管的云原生 MQTT 5.0 音讯服务，EMQ X Cloud 能够在数分钟内疾速创立一个 MQTT 服务，并且残缺反对 MQTT 5.0 协定，也是寰球首个全托管的 MQTT 5.0 私有云服务。 ...

EMQ X 是基于 Erlang/OTP 平台开发的开源物联网 MQTT 音讯服务器，目前广泛应用于寰球各行业物联网平台建设中。其设计指标是实现高牢靠承载海量物联网终端的 MQTT 连贯，反对在海量物联网设施间低延时音讯路由。 本文将以 EMQ X v4.3.10（开源版）为例，介绍 EMQ X 在 Docker、Kubernetes、Windows 和 Linux 上的装置办法以及常见问题，为大家利用 MQTT 音讯服务器疾速搭建物联网平台提供帮忙。 装置前查看绝大多数状况下操作系统的环境依赖、监听端口都不会呈现问题，测试环境下能够间接装置启动，EMQ X 会查看可能存在的问题并进行启动、报出谬误。 然而咱们依然倡议当生产环境存在降级 EMQ X 版本、降级其余服务等环境变动之后，再次启动 EMQ X 前务必进行测试和查看，防止产生不必要的损失。 查看环境依赖常见的因为环境依赖导致的问题如下： OpenSSL 版本不正确：常见于 CentOS 零碎上，须要更新 OpenSSL 版本缺失 MSVCRxxx.dll 文件：Windows 零碎特有，须要装置对应的依赖库安装包与操作系统不符：EMQ X 须要对应操作系统和版本下载，否则无奈启动并报 cannot execute binary file 谬误更多的问题和解决办法详见：EMQ X - 常见谬误 查看端口占用端口占用会导致 EMQ X 无奈启动或局部性能异样，常见的症状有： 执行 emqx start 时提醒启动超时无奈关上 Dashboard 或关上后始终报 404 Not Found 谬误呈现以上状况，能够应用 emqx console 命令启动 EMQ X，console 模式下能够打印具体的谬误日志。 ...

前言之前钻研了一段时间的 COAP 协定后果爱智那边没有测试工具，而后 arduino 也没有找到适合的库，我懒癌发生也懒得修这库，就只能十分难堪先临时放一放了。不过我在 爱智APP -> 设施 -> 设置 中发现爱智中做了一个 MQTT Broker ，也就是说我能利用精灵一号，在两块ESP32 之间进行通信了，而且 arduino 也有现成的库，而后我就突击了一下MQTT ，把这玩意给弄起来了，这里就给大家分享一下。 配置 MQTT Broker在爱智APP的设施中有个设置按钮： 在外面能够启用精灵一号的 MQTT Broker 性能并且进行设置：在 MQTT 的设置中能够配置相干参数：这些参数和与上面 ESP32 中的配置无关 代码获取我应用的 MQTT 库间接在 IDE 的库管理器里就能下载到：或者去GitHub下载： https://github.com/adafruit/A...而示例代码，老样子在灵感桌面的机密宝库 下载代码。或者间接 git clone: https://gitee.com/inspiration...外面有两个文件夹，别离是发布者和订阅者发的示例。 代码解析为了不便解说逻辑，我会打乱代码的程序可能还会进行裁剪。本 demo 基于 MQTT 库自带的 DEMO 批改而来。 创立 MQTT 客户端#include <WiFi.h>//#include "WiFiClientSecure.h"#include "WiFiClient.h"#include "Adafruit_MQTT.h"#include "Adafruit_MQTT_Client.h"/************************* WiFi Access Point *********************************/#define WLAN_SSID "EOS-Tenda"#define WLAN_PASS "1234567890"/************************* Adafruit.io Setup *********************************/#define AIO_SERVER "192.168.128.1"// 在爱智APP->设施->MQTT Broker 设置，能够看到并且设置#define AIO_SERVERPORT 1883// 在爱智APP->设施->MQTT Broker 设置，能够看到并且设置#define AIO_USERNAME "user"#define AIO_KEY "passwd"/************ Global State (you don't need to change this!) ******************/// 爱智仿佛没有这个平安模式，于是应用了 WiFiClient //WiFiClientSecure client;WiFiClient client;// 通过传入WiFi客户端和MQTT服务端以及登录详细信息来设置MQTT客户端类，留神连入爱智必须设置 cid，可能和爱智那边设置有关系。Adafruit_MQTT_Client mqtt(&client, AIO_SERVER, AIO_SERVERPORT, "Publish_cid", AIO_USERNAME, AIO_KEY);须要留神的是尽管 Adafruit_MQTT_Client 有能够不带 cid 的实现 ...

MQTT v5 带来了很多新的个性，咱们会尽量以通俗易懂的形式展现这些个性，并探讨这些个性对开发者的影响。到目前为止，咱们曾经探讨过这些 MQTT v5 新个性，明天咱们将持续探讨： 用户属性。 什么是用户属性用户属性（User Properties）其实是一种自定义属性，容许用户向 MQTT 音讯增加本人的元数据，传输额定的自定义信息以裁减更多利用场景。 它由一个用户自定义的 UTF-8 的键/值对数组组成，并在音讯属性字段中配置，只有不超过最大的音讯大小，能够应用有限数量的用户属性来向 MQTT 音讯增加元数据，并在发布者、MQTT 服务器和订阅者之间传递信息。 如果你相熟 HTTP 协定的话，该性能与 HTTP 的 Header 的概念十分相似。用户属性无效地容许用户扩大 MQTT 协定，并且能够呈现在所有音讯和响应中。因为用户属性是由用户定义的，它们只对该用户的实现有意义。 为什么须要应用用户属性MQTT 3 的协定扩展性能力较差，用户属性其实就是为了解决这个问题，它反对在音讯中传递任何信息，确保了用户可扩大标准协议的性能。 对于抉择和配置不同的音讯类型，用户属性能够在客户端与 MQTT 服务器之间，或者客户端和客户端之间发送。在连贯客户端中配置用户属性时，只能在 MQTT 服务器上接管，无奈在客户端中接管。如果在发送音讯的时候配置用户属性，则能够在其它客户端中接管。罕用的有以下两种用户属性配置。 连贯客户端的用户属性当客户端与 MQTT 服务器发动连贯时，服务器能够事后定义好一些须要并且能够应用到的元数据信息，即用户属性，当连贯胜利后，MQTT 服务能够拿到连贯发送过去的相干信息进行应用，因而连贯客户端的用户属性依赖于 MQTT 服务器。 音讯公布的用户属性音讯公布时的用户属性可能是较为罕用的，因为它们能够在客户端与客户端之间进行元数据信息传递。比方能够在公布时增加一些常见的信息：音讯编号，工夫戳，文件，客户端信息和路由信息等属性。 除上述较为罕用的用户属性设置外，还能够在订阅 Topic 时，勾销订阅时，断开连接时配置用户属性。 用户属性的应用文件传输MQTT 5 的用户属性，可扩大为应用其进行文件传输，而不是像之前的 MQTT 3 中将数据放到音讯体的 Payload 中，用户属性应用键值对的形式。这也意味着文件能够放弃为二进制，因为文件的元数据在用户属性中。例如： { "filename": "test.txt", "content": "xxxx"}资源解析当客户端连贯到 MQTT 服务器后，不同的客户端、供应商平台或零碎存在着不同的形式传递音讯数据，音讯数据的格局可能都存在着一些构造差别。还有一些客户端是散布在不同的地区下。比方：地区 A 的设施发送的音讯格局是 JSON 的，地区 B 的设施发送的是 XML 的，此时服务器接管到音讯后可能须要一一进行判断和比照，找到适合的解析器来进行数据解析。 此时为了提高效率和缩小计算负载，咱们能够利用用户属性性能来增加数据格式信息和地区信息，当服务器接管到音讯后，能够应用用户属性中提供的元数据来进行数据解析操作。并且当区域 A 的客户端订阅接管到来自区域 B 的客户端音讯时，也能疾速的分明特定的音讯的来自于哪个区域等，从而使的音讯具备了可追溯性。 ...

2017 年 8 月，OASIS MQTT Technical Committee 正式公布了用于 Public Review 的 MQTT 5.0 的草案。2018 年，MQTT 5.0 正式公布，然而直到目前苹果生态里仍没有残缺反对 MQTT 5.0 的客户端 SDK 。 CocoaMQTT 是 EMQ 团队为 iOS 开发者提供的 MQTT 客户端 SDK，目前在 iOS 开发者中有着较为宽泛的应用。 为补救苹果生态中对 MQTT 5.0 反对方面的空白，EMQ 团队于近日正式公布了 CocoaMQTT 全新版本 v2.0。CocoaMQTT v2.0 反对 MQTT 5.0，同时兼容 3.1.1 版本，反对 iOS、tvOS 与 OSX 操作系统。用户现已可通过 CocoaMQTT 实现 iOS 零碎设施连贯 MQTT 5.0 云服务，享受 MQTT 5.0 带来的弱小性能加成。 CocoaMQTT 应用 Swift 语言开发，而非 Objective-C。这是因为 Swift 是一门类型平安的语言，对协定的反对更加丰盛，配合扩大（extension）、泛型、关联类型等能够实现面向协定编程，从而大大提高代码的灵活性。 此外，在 WWDC 2021 大会上，苹果发表了 Swift 语言中并发模型的重大更新：通过编译器实现的 Actor 并发模型，新增 Actor 援用类型帮忙开发者防止数据竞争问题。 ...

前言很多 MQTT 我的项目和物联网服务都提供了在线的公共 MQTT 服务器，用户能够间接利用其进行 MQTT 学习、测试、原型制作甚至是小规模应用，而无需再自行部署，方便快捷，节省时间与精力老本。 但因为地理位置、网络环境以及服务器负载不同，每个公共服务器的稳定性以及音讯传输时延也不尽相同。只管简直所有服务提供方都申明不对其收费服务的稳定性和安全性负责，但用户在应用时却须要思考这些因素。 为此，本文整顿了一些较为热门的收费在线 MQTT 服务器，通过可拜访性、网络延时、小规模性能测试以及音讯理论传输延时等几个层面进行评估比照，心愿能够为您的抉择提供参考。 热门在线公共 MQTT 服务器本文选取了以下几个热门的在线公共 MQTT 服务器： 名称Broker 地址TCPTLSWebSocketEMQ Xbroker.emqx.io188388838083,8084EMQ X（国内）broker-cn.emqx.io188388838083,8084Eclipsemqtt.eclipseprojects.io1883888380, 443Mosquittotest.mosquitto.org18838883, 888480HiveMQbroker.hivemq.com1883N/A8000EMQ X收费在线的 MQTT 5 服务器，由 EMQ X Cloud 提供。为优化国内用户访问速度，别离提供了海内跟国内两个接入点，其中 EMQ X 部署在 AWS 美国俄勒冈区域，EMQ X（国内）部署在腾讯云上海区域，国内拜访有稳固的网络通道。 两个接入点均为 2 个节点组成的 EMQ X 集群，前期依据理论接入量和负载能够主动扩容更多节点。依据后盾显示，该服务器基于 EMQ X 企业版 4.2.6 版本，以后运行时长为 128 天。 具体介绍请拜访 EMQ 官网页面：收费的在线 MQTT 5 服务器。 注：EMQ X 与 EMQ X(国内) 两个接入点数据不互通。Eclipse由 Eclipse IoT 提供的收费在线 MQTT 服务器，解析到的 IP 显示其部署在 Azure 美国弗吉尼亚区域。值得一提的是此前该服务器的接入地址始终都是 mqtt.eclipse.org，不知因何故更换到当初的接入地址，撰写本文时我应用旧地址接入失败一度认为服务器曾经停了，最初通过 HTTP 拜访原接入点时才发现曾经做了 301 永恒重定向。 ...

PHPMQTT v1.4.1 版本公布，在此版本中次要是新增了一个协定调试工具。 提供了 5 种办法来调试二进制数据，实际上就是一个二进制数据查看工具。 次要是将二进制数据转为 ASCII、十六进制的格局进行查看，能够用来调试 TCP、WebSocket、UDP 等。 public function hexDump(): string // 以16进制显示public function hexDumpAscii(): string // 以16进制和相应的ASCII字符显示public function printableText(): string // 可打印字符public function hexStream(): string // 16进制流public function ascii(): string // 以ASCII字符显示应用能够通过实例化Simps\MQTT\Tools\Debug或者Simps\MQTT\Tools\Common/Simps\MQTT\Tools\UnPackTool动态调用： 实例化use Simps\MQTT\Tools\Debug;$debug = new Debug('0:simps-mqtt/user001/update{ "msg": "hello, mqtt"}');//$debug = (new Debug())->setEncode('0:simps-mqtt/user001/update{// "msg": "hello, mqtt"//}');echo $debug->hexDump(), PHP_EOL;echo $debug->hexDumpAscii(), PHP_EOL;echo $debug->printableText(), PHP_EOL;echo $debug->hexStream(), PHP_EOL;echo $debug->ascii();动态调用use Simps\MQTT\Tools\UnPackTool;echo UnPackTool::hexDumpAscii('0:simps-mqtt/user001/update{ "msg": "hello, mqtt"}');00000000 30 3a 73 69 6d 70 73 2d 6d 71 74 74 2f 75 73 65 0:simps-mqtt/use00000010 72 30 30 31 2f 75 70 64 61 74 65 7b 0a 20 20 22 r001/update{. "00000020 6d 73 67 22 3a 20 22 68 65 6c 6c 6f 2c 20 6d 71 msg": "hello, mq00000030 74 74 22 0a 7d tt".}在 Client 中应用调用配置对象的setVerbose办法，设置须要的调试级别即可。 ...

在这篇文章中，咱们将介绍 MQTT Broker 集群在可扩展性方面的一些改良。 咱们将次要关注 EMQ X 外部应用的数据库引擎，以及它在 EMQ X 5.0 版本中是如何改良的。 在开始本文之前，咱们须要理解 EMQ X 集群中是数据是如何复制的：EMQ X broker 将主题和客户端的运行时信息存储在 Mnesia 数据库中，有助于跨集群复制数据。 Mnesia 简介Mnesia 是一个开源数据库管理系统，由爱立信公司开发作为凋谢电信平台（ Open Telecom Platform ）的一部分，最后是用来解决 ISP 级电信交换机中的配置和运行时数据。EMQ X 4.3 之前的版本应用其来存储各种运行时数据，例如主题、路由、ACL 规定、告警等等。 MySQL、Postgres、MongoDB 等数据库以及 Redis 和 memcached 等内存存储大家应该都十分相熟，对 Mnesia 则可能不甚了解。但它的确有其独特的劣势，可将上述产品的许多性能集成到一个简洁的应用程序中。 Mnesia 有一个相当学术的定义：一个嵌入式、分布式、事务型的 noSQL（非关系型）数据库。听起来有些简单，咱们接下来将逐个为大家解释。 嵌入式MySQL 和 Postgres 等最宽泛应用的数据库广泛采纳客户端—服务器模式：数据库在独自的过程中运行（通常在专用服务器上），业务应用程序通过网络或 UNIX 域套接字发送申请并期待回答，通过这种形式来与数据库交互。这种模式在很多方面都很不便，因为它容许将业务逻辑与存储离开并独自治理。 但同时也有一些毛病：与近程过程交互不可避免地会减少每个申请的提早。 相同，嵌入式数据库与业务应用程序则在雷同的过程中运行。sqlite 是一个典型的嵌入式数据库的例子。Mnesia 也属于这一类：它与其余 EMQ X 应用程序在同一过程中运行。 从 Mnesia 表中读取数据能够像读取局部变量一样快，因而咱们能够在热点中读取数据库数据而不会影响性能。 分布式咱们之前提到过 Mnesia 是一个分布式数据库，这意味着数据表被网络复制到不同的物理地位。对于分布式数据库，如果节点之间不共享任何物理资源（如 RAM 或磁盘），而是在应用程序级别进行协调，这种类型称为无共享架构 (SN)。 这种类型通常是首选，因为它不须要任何专门的硬件，并且能够程度扩大。 Mnesia 应用程序与 EMQ X 一起运行，有助于通过 Erlang 散发协定跨集群中的所有节点复制表更新。 这意味着业务应用程序能够在本地读取更新的数据。它还有助于晋升容错性能：只有集群中有一个节点处于活动状态，数据就是平安的。EMQ X 依附此性能实现跨集群复制路由信息。 ...

在上一篇文章《MQTT Broker 集群详解（一）：负载平衡》中，咱们简略介绍了 MQTT 负载平衡：负载平衡既能够利用于传输层，也能够用于应用层。在本文中，咱们将具体介绍应用层负载平衡，其中最乏味的局部：粘性会话（sticky-session）。 本文由两局部组成，第一局部将介绍 MQTT 会话，以及在分布式 MQTT Broker 集群中解决会话面临的挑战；第二局部是通过在 EMQ X 4.3 集群后面配置 HAProxy 2.4 负载均衡器，带读者亲自体验如何充分利用粘性会话实现负载平衡。 MQTT 会话为了继续接管音讯，MQTT 客户端通常会连贯至 MQTT Broker 进行订阅并放弃长期连贯。因为网络问题或客户端软件维护等起因，连贯可能会中断一段时间，这并不常见，但客户端通常心愿在从新连贯胜利后依然能接管到中断期间漏收的音讯。 因而，为客户端提供服务的 MQTT Broker 应该为客户端放弃会话（依据客户端的申请，将「Clean-Session」标记设置为 false）。此时，即便客户端断开连接，订阅者以后订阅的主题以及传递给这些主题的音讯（QoS1 和 2）等也会由音讯服务器（broker）保留。 当具备长久会话的客户端从新连贯时，它不须要从新订阅主题，音讯服务器应该将所有未发送的音讯发送给该客户端。 咱们之前写过一篇对于 MQTT 会话的文章，如果您对 MQTT 会话的技术细节感兴趣，能够通过浏览这篇文章做进一步理解。 会话接管当 MQTT Brokers 造成集群时，事件会变得更加简单。从客户端的角度来看，要连贯的服务器不止一个，很难晓得哪个服务器最适宜连贯。咱们须要网络中的另一个要害组件：负载均衡器。负载均衡器成为整个集群的接入点，并将客户端的连贯路由到集群中的某一个服务器。 如果客户端通过负载均衡器连贯到服务器（例如，node1），而后断开连接并稍后从新连贯，则新连贯可能会路由到集群中的不同服务器（例如，node3）。在这种状况下，node3 应该在客户端断开连接时开始向客户端发送未发送的音讯。 实现集群范畴的长久会话有很多不同的策略。例如，整个集群能够共享一个全局存储来保留客户端的会话。 然而，更具可扩展性的解决方案通常以分布式形式解决这个问题，即数据从一个节点迁徙到另一个节点。这种迁徙称为会话接管。会话接管应该对客户端齐全通明，但它是有代价的，尤其是当有很多音讯须要解决时。 粘性会话解决方案这里的「粘性」一词指的是负载均衡器可能在从新连贯时将客户端路由到之前服务器的能力，这能够防止会话接管。当有许多客户端在同一时间从新连贯时，或者在一个有问题的客户端重复断开连接并再次连贯的状况下，这是一个特地有用的性能。 为了让负载均衡器以「粘性」形式分派连贯，服务器须要晓得连贯申请中的客户端标识符（有时是用户名）——这须要负载均衡器查看 MQTT 数据包以查找此类信息。 一旦取得客户端标识符（或用户名），对于动态集群，服务器能够将客户端标识符（或用户名）散列到服务器 ID。或者为了更好的灵活性，负载均衡器能够抉择保护一个从客户端标识符（或用户名）到指标节点 ID 的映射表。 在下一节中，咱们将演示 HAProxy 2.4 中的粘性表策略。 应用 HAProxy 2.4 实现粘性会话为了尽量减少先决条件，在这个演示集群中，咱们将在 docker 容器中启动两个 EMQ X 节点和一个 HAProxy 2.4。 ...

一、前言在连肝了一个多月之后，mica-mqtt 迎来了一个比较稳定的版本。在这一个多月里肝了 7 个正式版，100 屡次提交。由衷感谢那些在关注、star、应用和反馈问题的同学。 二、简介mica-mqtt 基于 t-io 实现的简略、低提早、高性能 的 mqtt 物联网开源组件。应用详见 mica-mqtt gitee 源码 mica-mqtt-example 模块。 三、性能[x] 反对 MQTT v3.1、v3.1.1 以及 v5.0 协定。[x] 反对 websocket mqtt 子协定（反对 mqtt.js）。[x] 反对 http rest api，http api 文档详见。[x] 反对 MQTT client 客户端。[x] 反对 MQTT server 服务端。[x] 反对 MQTT 遗嘱音讯。[x] 反对 MQTT 保留音讯。[x] 反对自定义音讯（mq）解决转发实现集群。[x] MQTT 客户端 阿里云 mqtt 连贯 demo。[x] 反对 GraalVM 编译老本机可执行程序。[x] 反对 Spring boot 我的项目疾速接入（mica-mqtt-spring-boot-starter）。[x] mica-mqtt-spring-boot-starter 反对对接 Prometheus + Grafana。四、更新记录 mqtt-server 优化连贯敞开日志。 mqtt-server 优化订阅，雷同 topicFilter 订阅对 qos 判断。 mqtt-server 监听器增加 try catch，防止因业务问题导致连贯断开。 mqtt-server 优化 topicFilters 校验。 mqtt-client 优化订阅 reasonCodes 判断。 mqtt-client 监听器增加 try catch，防止因业务问题导致连贯断开。 mqtt-client 增加 session 有效期。 代码优化，缩小 codacy 上的问题。 mqtt-server 修复心跳工夫问题。 修复 mqtt-server 多个订阅同时匹配时音讯反复的问题。 mqtt-client 优化连贯解决的逻辑，mqtt 连贯之后再订阅。 修复 MqttProperties 潜在的一个空指针。五、Spring boot 疾速接入5.1 增加依赖<dependency> <groupId>net.dreamlu</groupId> <artifactId>mica-mqtt-spring-boot-starter</artifactId> <version>1.1.1</version></dependency>5.2 服务端配置示例mqtt: server: enabled: true # 是否开启，默认：true ip: 127.0.0.1 # 服务端 ip 默认：127.0.0.1 port: 5883 # 端口，默认：1883 name: Mica-Mqtt-Server # 名称，默认：Mica-Mqtt-Server buffer-allocator: HEAP # 堆内存和堆外内存，默认：堆内存 heartbeat-timeout: 120000 # 心跳超时，单位毫秒，默认: 1000 * 120 read-buffer-size: 8092 # 接收数据的 buffer size，默认：8092 max-bytes-in-message: 8092 # 音讯解析最大 bytes 长度，默认：8092 debug: true # 如果开启 prometheus 指标收集倡议敞开 websocket-enable: true # 开启 websocket 子协定，默认开启 websocket-port: 8083 # websocket 端口，默认：80835.3 服务端可实现接口（注册成 Spring Bean 即可）接口是否必须阐明IMqttServerAuthHandler是用于客户端认证IMqttMessageListener是音讯监听IMqttConnectStatusListener是连贯状态监听IMqttSessionManager否session 治理IMqttMessageStore集群是，单机否遗嘱和保留音讯存储AbstractMqttMessageDispatcher集群是，单机否音讯转发，（遗嘱、保留音讯转发）IpStatListener否t-io ip 状态监听5.4 服务端自定义配置（可选）@Configuration(proxyBeanMethods = false)public class MqttServerCustomizerConfiguration { @Bean public MqttServerCustomizer activeRecordPluginCustomizer() { return new MqttServerCustomizer() { @Override public void customize(MqttServerCreator creator) { // 此处可自定义配置 creator，会笼罩 yml 中的配置 System.out.println("----------------MqttServerCustomizer-----------------"); } }; }}5.5 MqttServerTemplate 应用示例import net.dreamlu.iot.mqtt.codec.MqttQoS;import net.dreamlu.iot.mqtt.spring.server.MqttServerTemplate;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import java.nio.ByteBuffer;/** * @author wsq */@Servicepublic class ServerService { @Autowired private MqttServerTemplate server; public boolean publish(String body) { server.publishAll("/test/123", ByteBuffer.wrap(body.getBytes())); return true; }}5.6 基于 mq 音讯播送集群解决实现 IMqttConnectStatusListener 解决设施状态存储。实现 IMqttMessageListener 将音讯转发到 mq，业务按需解决 mq 音讯。实现 IMqttMessageStore 存储遗嘱和保留音讯。实现 AbstractMqttMessageDispatcher 将音讯发往 mq，mq 再播送回 mqtt 集群，mqtt 将音讯发送到设施。业务音讯发送到 mq，mq 播送到 mqtt 集群，mqtt 将音讯发送到设施。5.7 Prometheus + Grafana 监控对接得益于 t-io 良好的设计，监控指标间接对接的 t-iostat，目前反对下列指标，前期会不断完善。 ...

微信小程序是腾讯于 2017 年 1 月 9 日推出的一种不须要下载安装即可在微信平台上应用的应用程序，用户扫一扫或者搜一下即可关上利用。也体现了“用完即走”的理念，用户不必关怀是否装置太多利用的问题。利用将无处不在，随时可用，但又无需装置卸载。对于开发者而言，小程序开发门槛绝对较低，难度不迭 APP，可能满足简略的根底利用，对于用户来说，可能节约使用工夫老本和手机内存空间，对于开发者来说也能节约开发和推广老本。 本文次要介绍如何在微信小程序我的项目中应用 MQTT，实现小程序客户端与 MQTT 云服务的连贯、订阅、收发音讯、勾销订阅等性能。 MQTT 是一种基于公布/订阅模式的轻量级物联网音讯传输协定，能够用极少的代码和带宽为联网设施提供实时牢靠的音讯服务，它广泛应用于物联网、挪动互联网、智能硬件、车联网、电力能源等行业。我的项目初始化后期筹备注册微信小程序帐号，并下载微信开发者工具。因为微信小程序平安要求比拟高，在与后盾服务器之间的通信必须应用 https 或 wss 协定，因而要在微信小程序后盾设置域名服务器。 微信小程序仅反对通过 WebSocket 进行即时通信，EMQ X 的 MQTT Over WebSocket 可能齐全兼容应用在微信小程序上。但因为微信小程序的标准限度，EMQ X 应用微信小程序接入时须要留神以下几点： 应用曾经通过域名备案的域名接入域名须要微信公众平台登录后在主页面的服务器域名下增加配置服务器域名地址仅反对 WebSocket/TLS 协定，须要为域名调配受信赖 CA 颁发的证书因为微信小程序 BUG，安卓真机必须应用 TLS/443 端口，否则会连贯失败（即连贯地址不能带端口）增加服务器域名，这里咱们将 broker.emqx.io 为例增加到服务器域名中，咱们进入到页面中抉择开始配置按钮，在 socket 非法域名列下输出 wss://broker.emqx.io，留神：必须以 wss 协定结尾，如下图： 增加实现后，在微信小程序开发时才容许咱们于该域名地址下的服务器进行通信与交互。 新建我的项目筹备实现后期网络通讯相干工作后，咱们关上曾经下载好了的微信开发者工具，关上后在页面点击新建一个小程序我的项目，如下图所示： 点击确认后，微信开发者工具就主动初始化好了我的项目，咱们就能够开始开发了。 装置 MQTT 客户端库因为小程序是通过 JavaScript 开发的，因而能够应用 MQTT.js 作为 MQTT 客户端库。 从小程序根底库版本 2.2.1 或以上、及开发者工具 1.02.1808300 或以上开始，小程序反对应用 npm 装置第三方包。如感兴趣的读者可自行查看小程序 npm 反对的官网文档来操作应用，本文为简化操作过程，将不应用 npm 的形式装置。咱们将在 utils 文件夹下新建一个 mqtt.js 文件，咱们间接获取在 MQTT.js CDN 上的打包构建后的源码复制 mqtt.js 文件中。 ...

简介MQTT.js 是一个开源的 MQTT 协定的客户端库，应用 JavaScript 编写，次要用于 Node.js 和 浏览器环境中。是目前 JavaScript 生态中应用最为宽泛的 MQTT 客户端库。 MQTT 是一种基于公布/订阅模式的轻量级物联网音讯传输协定，能够用极少的代码和带宽为联网设施提供实时牢靠的音讯服务，它广泛应用于物联网、挪动互联网、智能硬件、车联网、电力能源等行业。因为 JavaScript 单线程个性，MQTT.js 是全异步 MQTT 客户端，MQTT.js 反对 MQTT/TCP、MQTT/TLS、MQTT/WebSocket，在不同运行环境反对的度如下： 浏览器环境：MQTT over WebSocket（包含微信小程序、支付宝小程序等定制浏览器环境）Node.js 环境：MQTT、MQTT over WebSocket不同环境里除了少部分连贯参数不同，其余 API 均是雷同的。且在 MQTT.js v3.0.0 及以上版本后，曾经残缺反对到 MQTT 5.0。 装置应用 npm 或 yarn 装置npm install mqtt --save# 或应用 yarnyarn add mqtt留神：如果您的 Node 环境是 v12 或 v14 及以上版本，请应用 MQTT.js 4.0.0 及以上版本 应用 CDN 装置在浏览器环境中，咱们还能够应用 CDN 的形式引入 MQTT.js。MQTT.js 的 bundle 包通过 http://unpkg.com 治理，咱们能够间接增加 unpkg.com/mqtt/dist/mqtt.min.js 来进行应用。 ...

本文素材来源于 RabbitMQ Summit 2019 会议上 Erlang Solutions 工程师 Grigory Starinkin 的发言内容。原内容次要对 MQTT 音讯服务器 EMQ X 与 RabbitMQ 进行了介绍及压力测试比照。在此基础上，咱们对其进行了补充，深入分析了 EMQ X 以及 RabbitMQ 的在外围架构上的偏重，并据此剖析了它们为 MQTT 集群模式体现带来的不同影响。 MQTT 协定 - 订阅和公布MQTT 是一个十分轻量级的订阅和公布协定，当初曾经是物联网畛域最具统治位置和应用最宽泛的传输协定。MQTT 协定每个音讯起码仅需 2 个字节 （其中报头仅需 1 个字节，其余字节能够全副作为音讯载荷）就能够实现通信，专为那些资源和空间无限、功耗敏感的硬件所打造。其次要模式是 Pub/Sub（公布/订阅），客户端能够表演两个角色，一个角色是发布者，其在连贯到服务器之后将针对某个特定主题发送音讯给服务器；另一个角色是订阅者，能够订阅感兴趣的主题来接管其中的音讯。订阅者也能够应用通配符订阅主题，这样就能够一次订阅多个不同的主题，还能够应用共享订阅进行负载平衡散发。 以下图片揭示了 MQTT 协定是如何运作的： 目前市场上有很多 MQTT 客户端 SDK，也有很多 MQTT Broker。EMQ X 和 RabbitMQ 是 Erlang 家族中具备代表性的两大开源音讯服务器，咱们接下来将针对 MQTT 场景对其进行深刻比照。 EMQ X 与 RabbitMQEMQ X 是基于高并发的 Erlang/OTP 语言平台开发，反对百万级连贯、分布式集群架构、公布订阅模式的开源 MQTT 音讯服务器。开源至今，EMQ X 在寰球物联网市场失去了广泛应用。在开源版根底上，还陆续倒退了商业版和提供云版本（cloud-hosting）（https://www.emqx.com/zh/cloud）。EMQ X 反对很多插件，具备弱小拓展能力，用户依附插件能够实现更多的性能。 ...

MQTT 协定概述MQTT 是用于物联网的规范消息传递协定。它被设计为一种十分轻量级的公布/订阅音讯传送，非常适合以较小的代码占用量和网络带宽连贯近程设施。MQTT 协定具备以下特点： 笨重高效：MQTT 客户端十分小，须要设施资源少。MQTT 音讯头很小，能够优化网络带宽。双向通信：MQTT 容许设施到云之间以及云到设施之间的消息传递。牢靠的消息传递：MQTT 具备3种定义的服务质量级别：0-最多一次，1-至多一次，2-恰好一次，可依据业务场景保障消息传递的可靠性。反对不牢靠网络：许多物联网设施通过不牢靠的蜂窝网络进行连贯。MQTT 对持久性会话的反对缩小了将客户端与代理从新连贯的工夫。平安：MQTT 使您能够轻松地应用 TLS 加密音讯并应用古代身份验证协定（例如OAuth）对客户端进行身份验证。现在，MQTT 被广泛应用于汽车、制造业、电信、石油和天然气等行业。 本系列文章将具体解读 MQTT 协定在各行业理论利用场景中是如何发挥作用的。 以后的工业 PLC 数据采集PLC 即可编程逻辑控制器，是工业自动化畛域的外围设施，广泛应用于各个工业畛域。从 PLC 问世至今，始终体现出弱小的生命力和高速增长态势，2020 年寰球 PLC 市场的销售量曾经达到了百亿 RMB 级别。 德国产业界将 PLC 在生产工艺自动化过程中的广泛应用定义为「工业 3.0」，其代表了各类数控机床、工业机器人等单机自动化设施在生产环节的推广及利用。而将无处不在的传感器、PLC、智能控制系统、通信设施通过 ICT 技术造成一个智能网络，使人与人、人与机器、机器与机器及服务与服务之间可能互联，则是「工业 4.0」的外围要义。人、物、数据通过物联网技术进行流程再造，由单机智能降级为万物互联的智能。 实现工业场景下的万物互联离不开对工业自动化设施的数据采集。其中 PLC 罕用的工业现场总线协定就多达数十种，此外各大 PLC 厂商根本都有各自的公有总线协定。因为现场总线品种繁多各异，传统的工业 PLC 数据采集个别通过在设施侧部署边缘网关的形式进行：应用边缘网关将各类协定对立，再将 PLC 数据采集及汇聚，转发到 IoT 平台，以此实现设施间的数据互联。 然而，基于边缘网关的数据采集形式，存在以下有余： 须要部署边缘网关硬件，并进行软件配置，须要投入额定的老本。边缘网关数据采集频率只能达到秒级，大部分边缘网关上报物联网平台的数据格式无奈批改。PLC 与边缘网关间通信呈现问题，会造成数据采集缺失，无奈为高级利用提供无效数据撑持。新趋势：PLC 集成 MQTT 协定随着物联网、大数据及人工智能的迅速倒退，自动化厂商也在减速推进物联网策略，推出各自的 IoT 和数字化解决方案。作为支流物联网协定的 MQTT 协定成为各自动化设施厂商关注的重点。为了减速实现互联互通的工业物联网，各大厂商纷纷开始在 PLC 中集成 MQTT 协定，以不便 PLC 数据的采集。 以几个支流厂商为例： 西门子曾经将 MQTT 客户端性能封装成 PLC 的库文件，通过西门子 S7-1200、S7-1500 能够实现基于 MQTT 3.1.1 协定的数据上报，实现 PLC 与 MQTT 音讯服务器的轻松连贯。德国倍福推出了 TF6701 IOT 通信库，通过 MQTT 协定能够将 PLC 数据间接发往各大公有云 IoT 平台以及 MQTT 音讯服务器；TF6701 同时反对将 PLC 中数据封装成 json 格局，实现数据上报，实现 OT 和 IT 畛域的数据格式统一化。 ...

MQTT 协定在物联网，小型设施场景，挪动利用等方面曾经有了宽泛的利用，并逐步成为了物联网通信的规范。本文重点介绍了组建 MQTT Broker 集群的挑战及负载平衡在 MQTT 集群中所起的作用。 MQTT 协定与大家相熟的 HTTP 协定相似，MQTT 协定同样基于 TCP/TLS 之上，属于应用层协定（它也能够基于 HTTP 协定之上工作，本文暂不波及这部分内容）。 MQTT 规范委员会对 MQTT 协定的释义如下： MQTT 是用于物联网 (IoT) 的 OASIS 规范消息传递协定。它是一种十分轻量级的音讯传输协定，采纳了公布/订阅的机制，非常适合连贯近程设施，无论是代码占用空间还是网络带宽的占用都很小。现在，MQTT 已被宽泛用于汽车、工业制作、电信、石油和天然气等各个行业。 MQTT 客户端和 HTTP 客户端也很类似。它与服务器端建设一个 TCP 连贯，通过该连贯传输数据。不同的是，HTTP 采纳的是申请/响应模型，而 MQTT 采纳的是公布/订阅模型。 举个例子：客厅里装置的温度传感器，会间断性的把室内温度数值上传到 MQTT 服务器上。而另一个智能家居设施订阅了这个温度传感器公布音讯的频道，就能够取得室内的温度数据，并依据理论室温采取一些智能应答措施，比方当室内温度超过 32°C 时就关上空调。 可拓展性挑战MQTT 协定听起来仿佛离咱们很边远，其实它早已渗透到了咱们的日常生活中。个别状况下，单个 MQTT 节点就能够满足单个家庭的智能家居设施连贯需要，用户甚至能够在树莓派上运行一个 EMQ X Edge （运行在边缘端的 MQTT 服务器）。而运行在云端的一个 EMQ X 节点能够撑持高达 200 万的连接数，轻松满足一般智能家居场景需要。 但如果是全国的千百万辆汽车要联网，或者是上百万盏路灯要传递数据之类的场景，那么微小的设施数（MQTT 客户端）和数据吞吐量，就远远超出了单个 MQTT 节点所能接受的压力，须要组建 MQTT 服务器集群。 在组建集群的同时，也面临着一系列的技术挑战： 提供服务地址：如何让客户端晓得该连贯哪个地址？不同节点如何接管 MQTT 订阅者的会话，比方当一个客户端从一台服务器断连后，要如何在另一台服务器复原连贯？集群中各个节点上的路由表如何放弃一致性？通过在 MQTT 集群后面引入一个负载平衡，能够帮忙咱们轻松解决问题 1 和 2。 ...

MQTT 是用于物联网的规范消息传递协定。它被设计为一种十分轻量级的公布/订阅音讯传送，非常适合以较小的代码占用量和网络带宽连贯近程设施。MQTT 协定具备以下特点： 笨重高效：MQTT 客户端十分小，须要设施资源少。MQTT 音讯头很小，能够优化网络带宽。双向通信：MQTT 容许设施到云之间以及云到设施之间的消息传递。牢靠的消息传递：MQTT 具备3种定义的服务质量级别：0-最多一次，1-至多一次，2-恰好一次，可依据业务场景保障消息传递的可靠性。反对不牢靠网络：许多物联网设施通过不牢靠的蜂窝网络进行连贯。MQTT 对持久性会话的反对缩小了将客户端与代理从新连贯的工夫。平安：MQTT 使您能够轻松地应用 TLS 加密音讯并应用古代身份验证协定（例如OAuth）对客户端进行身份验证。现在，MQTT 被广泛应用于汽车、制造业、电信、石油和天然气等行业。 本系列文章将具体解读 MQTT 协定在各行业理论利用场景中是如何发挥作用的。 电信运营商边缘设施治理面临的挑战电信运营商传统挪动业务和固网宽带业务市场趋势饱和，三大运营商的竞争也随之愈发强烈。在国家提速降费的政策导向下，传统业务的收益一直降落，倒退空间无限。将来 5G 终端用户、5G 利用和海量的智能 IoT 设施将是运营商的重要增量市场。 电信运营商接入网（含无线）、传输网、核心网、城域网等网络通过 SNMP、CLI、Netconf、TR069 等协定实现了欠缺的网络管理，然而针对海量的边缘网关（企业或家庭）和 IoT 设施治理仍有待欠缺，面临以下挑战： 海量设施治理难：截至 2020 年中国物联网设施和边缘网关总量超过百亿，物联网设施年增长率超过 60%，传统的电信级 OSS 零碎无奈撑持如此规模的设施治理。设施无独立治理 IP：海量的物联网设施和边缘网关没有独立的治理 IP，通过传统的 SNMP、CLI、NETCONF 等协定无奈实现设施治理。低功耗、弱网环境下的牢靠通信：IoT 设施资源受限且有低功耗需要，须要轻量的网络协议进行治理。低时延要求：局部 5G 垂直利用场景（如工控、车联网）对音讯时延有很高的要求。基于 MQTT 的物联网最初一公里网络管理随着物联网技术的疾速倒退，轻量级 MQTT 协定逐步成为支流物联网协定，广泛应用于 IoT 设施音讯通信。MQTT 协定也完满解决了运营商在 IoT 边缘侧面临的上述问题。 运营商物联网 MQTT 音讯接入示意图 以 EMQ 面向运营商的云边一体化解决方案为例： EMQ 面向运营商的云边一体化解决方案 应用 MQTT 协定对立接入海量边缘设施针对工业制作、智慧矿山、能源电力等场景中波及到 Modbus、OPC-UA、IEC 等各类不同的 PLC 工业协定，能够先通过 EMQ 提供的物联网边缘工业协定网关软件 Neuron 对立转换成 MQTT 协定，再通过 EMQ X 高可用、分布式集群架构构建物联网治理平台，实现设施数据的连贯、挪动及后续的解决与剖析，解决海量设施治理问题。 ...

一、简介mica-mqtt 基于 t-io 实现的简略、低提早、高性能 的 mqtt 物联网开源组件。应用详见 mica-mqtt gitee 源码 mica-mqtt-example 模块。 二、性能[x] 反对 MQTT v3.1、v3.1.1 以及 v5.0 协定。[x] 反对 MQTT client 客户端。[x] 反对 MQTT server 服务端。[x] 反对 MQTT 遗嘱音讯。[x] 反对 MQTT 保留音讯。[x] 反对自定义音讯（mq）解决转发实现集群。[x] MQTT 客户端 阿里云 mqtt 连贯 demo。[x] 反对 GraalVM 编译老本机可执行程序。[x] 反对 Spring boot 我的项目疾速接入（mica-mqtt-spring-boot-starter）。[x] mica-mqtt-spring-boot-starter 反对对接 Prometheus + Grafana。三、待办[ ] 增加 websocket 反对（已预研胜利）。[ ] 优化解决 mqtt session，以及反对 v5.0四、更新记录 文档增加集群解决步骤阐明，增加遗嘱音讯、保留音讯的应用场景。✨ 去除演示中的 qos2 参数，性能损耗大防止误用。✨ 遗嘱、保留音讯内部消息转发形象。✨ 增加 mica-mqtt-spring-boot-example 。感激 wsq（ @冷月宫主 ）pr。✨ mica-mqtt-spring-boot-starter 反对客户端接入和服务端优化。感激 wsq（ @冷月宫主 ）pr。✨ mica-mqtt-spring-boot-starter 服务端反对指标收集。可对接 Prometheus + Grafana 监控。✨ mqtt server 承受连贯时，先判断该 clientId 是否存在其它连贯，有则解绑并敞开其余连贯。⬆️ 降级 mica-auto 到 2.1.3 修复 ide 多模块增量编译问题。五、Spring boot 疾速接入5.1 增加依赖<dependency> <groupId>net.dreamlu</groupId> <artifactId>mica-mqtt-spring-boot-starter</artifactId> <version>1.0.2</version></dependency>5.2 服务端 yml 配置mqtt: server: enabled: true # 是否开启，默认：true ip: 127.0.0.1 # 服务端 ip 默认：127.0.0.1 port: 5883 # 端口，默认：1883 name: Mica-Mqtt-Server # 名称，默认：Mica-Mqtt-Server buffer-allocator: HEAP # 堆内存和堆外内存，默认：堆内存 heartbeat-timeout: 120000 # 心跳超时，单位毫秒，默认: 1000 * 120 read-buffer-size: 8092 # 接收数据的 buffer size，默认：8092 max-bytes-in-message: 8092 # 音讯解析最大 bytes 长度，默认：8092 debug: true # 如果开启 prometheus 指标收集倡议敞开5.3 服务端可实现接口（注册成 Spring Bean 即可）接口是否必须阐明IMqttServerAuthHandler是用于客户端认证IMqttMessageListener是音讯监听IMqttConnectStatusListener是连贯状态监听IMqttSessionManager否session 治理IMqttMessageStore集群是，单机否遗嘱和保留音讯存储AbstractMqttMessageDispatcher集群是，单机否音讯转发，（遗嘱、保留音讯转发）IpStatListener否t-io ip 状态监听5.4 服务端自定义配置（可选）@Configuration(proxyBeanMethods = false)public class MqttServerCustomizerConfiguration { @Bean public MqttServerCustomizer activeRecordPluginCustomizer() { return new MqttServerCustomizer() { @Override public void customize(MqttServerCreator creator) { // 此处可自定义配置 creator，会笼罩 yml 中的配置 System.out.println("----------------MqttServerCustomizer-----------------"); } }; }}5.5 MqttServerTemplate 应用示例import net.dreamlu.iot.mqtt.codec.MqttQoS;import net.dreamlu.iot.mqtt.spring.server.MqttServerTemplate;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import java.nio.ByteBuffer;/** * @author wsq */@Servicepublic class ServerService { @Autowired private MqttServerTemplate server; public boolean publish(String body) { server.publishAll("/test/123", ByteBuffer.wrap(body.getBytes())); return true; }}5.6 基于 mq 音讯播送集群解决实现 IMqttConnectStatusListener 解决设施状态存储。实现 IMqttMessageListener 将音讯转发到 mq，业务按需解决 mq 音讯。实现 IMqttMessageStore 存储遗嘱和保留音讯。实现 AbstractMqttMessageDispatcher 将音讯发往 mq，mq 再播送回 mqtt 集群，mqtt 将音讯发送到设施。业务音讯发送到 mq，mq 播送到 mqtt 集群，mqtt 将音讯发送到设施。5.7 Prometheus + Grafana 监控对接得益于 t-io 良好的设计，监控指标间接对接的 t-io stat，目前反对下列指标，前期会不断完善。 ...

本文将以 MQTT.fx 作为 MQTT 客户端测试工具，接入 MQTT 云服务 - EMQ X Cloud。通过本文，你将能疾速理解 MQTT.fx 的根底用法以及 MQTT 协定的基本概念与应用。 MQTT.fx 简介MQTT.fx 是目前最为风行的 MQTT 桌面客户端工具，MQTT.fx 1.0 Major 版本由 Jens Deters 应用JavaFX 技术开发，即为 Java 虚拟机利用。遗憾的是 MQTT.fx 目前曾经进行保护，并转为由 Softblade 公司赞助开发另发行了其商业版本 MQTT.fx® 5.0，采纳免费许可证形式经营该软件。本文中的 MQTT.fx 不经非凡阐明即特指 1.0 版本。 它蕴含支流的 MQTT 客户端性能： 根本订阅/推送/连接功能用户认证SSL/TLS连贯反对易用的音讯编辑栏反对代理此外 MQTT.fx 也有其余优良个性: 软件自在，其开源协定为 Apache 2.0 license反对跨平台反对 $SYS 主题订阅治理 MQTT Broker残缺的日志控制台反对 JavaScript 脚本解决音讯反对预约义模版但同时也有缺点： 不反对 MQTT 5.0 协定一次只能建设一个连贯，不不便多连贯调试不反对 WebSocket 协定，无奈调试 MQTT over Webscoket 的状况EMQ X Cloud 简介EMQ X Cloud 是由 EMQ 公司推出的可连贯海量物联网设施，集成各类数据库及业务零碎的全托管云原生 MQTT 服务。作为寰球首个全托管的 MQTT 5.0 私有云服务，EMQ X Cloud 提供了一站式运维代管、独有隔离环境的 MQTT 音讯服务。 ...

本文将以 MQTTBox 作为 MQTT 客户端测试工具，接入 MQTT 云服务 - EMQ X Cloud。通过本文，你将能疾速理解 MQTTBox 的根底用法以及 MQTT 协定的基本概念与应用。 MQTTBox 简介MQTTBox 是 Sathya Vikram 集体开发的 MQTT 客户端工具，最后仅在 Chrome 上作为拓展装置应用， 后经重写开源成为桌面端跨平台软件。界面简略间接，反对多个客户端同时在线，但客户端之间的切换、互发音讯等交互还是有一些不便。MQTTBox 借助 Chrome 实现弱小的跨平台个性，联合简略的负载测试性能，是一款值得尝试的 MQTT 客户端工具。 MQTTBox 残缺的反对了以下性能： 通过反对 Chrome OS，Linux，macOS，Windows 的 Chrome 存储易于装置，反对 Linux、macOS、Windows 独立装置反对 MQTT、MQTT over WebSocket，多种 TCP 加密形式的连贯保留发送的音讯历史记录复制/粘贴历史记录中的音讯保留订阅音讯历史记录简略的性能测试，对 Broker 的负载做出测试并通过图表可视化查看测试后果EMQ X Cloud 简介EMQ X Cloud 是由 EMQ 公司推出的可连贯海量物联网设施，集成各类数据库及业务零碎的全托管云原生 MQTT 服务。作为寰球首个全托管的 MQTT 5.0 私有云服务，EMQ X Cloud 提供了一站式运维代管、独有隔离环境的 MQTT 音讯服务。 在万物互联的时代，EMQ X Cloud 能够帮忙用户疾速构建面向物联网畛域的行业利用，轻松实现物联网数据的采集、传输、计算和长久化。 ...

本文将以 MQTTLens 作为 MQTT 客户端测试工具，接入 MQTT 云服务 - EMQ X Cloud。通过本文，你将能疾速理解 MQTTLens 的根底用法以及 MQTT 协定的基本概念与应用。 MQTTLens 简介MQTTLens 是有一个 Chrome 拓展工具，能够通过 Chrome 网上利用商店装置。MQTTLens 界面十分简洁，提供根底的公布订阅性能。 MQTTLens 足够简略，借助 Chrome 有很弱小的跨平台个性提供了根底的 MQTT 和 MQTT over WebSocket 连接功能，能够疾速满足入门摸索应用。 MQTTLens 残缺的反对了以下性能： 能同时与多个 MQTT 服务器建设连贯，并采纳不同色彩区别订阅、公布和查音讯的界面非常简单且易于把握反对 MQTT 和 MQTT over WebSocketEMQ X Cloud 简介EMQ X Cloud 是由 EMQ 公司推出的可连贯海量物联网设施，集成各类数据库及业务零碎的全托管云原生 MQTT 服务。作为寰球首个全托管的 MQTT 5.0 私有云服务，EMQ X Cloud 提供了一站式运维代管、独有隔离环境的 MQTT 音讯服务。 在万物互联的时代，EMQ X Cloud 能够帮忙用户疾速构建面向物联网畛域的行业利用，轻松实现物联网数据的采集、传输、计算和长久化。 本文将应用 EMQ X Cloud 提供的 收费公共 MQTT 服务器 作为本次测试的 MQTT 服务器地址，服务器接入信息如下： ...

本文将以 MQTT Explorer 作为 MQTT 客户端测试工具，接入 MQTT 云服务 - EMQ X Cloud。通过本文，你将能疾速理解 MQTT Explorer 的根底用法以及 MQTT 协定的基本概念与应用。 MQTT Explorer 简介MQTT Explorer 是目前较为沉闷的 MQTT 客户端桌面利用，始终受到开发者们的青睐。次要技术是 Electron，由 @thomasnordquist 开发并且开源，遵循 Creative Commons Public Licenses 协定，GitHub 地址为 https://github.com/thomasnord...。 其蕴含次要个性有： 根本订阅/推送/连接功能用户认证性能WebSocket 反对反对 diff 查看和多种类型的 Payload根本的历史信息日志反对 TLS 连贯反对黑夜模式尤其是一些较好的个性有： 主动订阅$SYS主题，不便查看 broker 状态信息依照树形构造组织订阅列表，不便用户查看其归属关系有音讯可视化性能，直观、可交互的统计图表设计MQTT Explorer 可能满足大部分开发的需要，然而也有一些毛病： 一次只能一个连贯存在，不不便多连贯调试UI 设计上 Publish payload 和 Subscribe Message list 没有离开，并不能很不便地查看收发信息的状况没有残缺的操作日志记录，不不便开发者排查与服务器交互的信息EMQ X Cloud 简介EMQ X Cloud 是由 EMQ 公司推出的可连贯海量物联网设施，集成各类数据库及业务零碎的全托管云原生 MQTT 服务。作为寰球首个全托管的 MQTT 5.0 私有云服务，EMQ X Cloud 提供了一站式运维代管、独有隔离环境的 MQTT 音讯服务。 ...

依赖 composer require php-mqtt/client v1.1.0应用 $mqtt - new MqttService([ 'acessKeyID' => 'XXXX',//账号的 AccessKey，在阿里云控制台查看 'accessKeySecret' => 'XXXX', //账号的的 SecretKey，在阿里云控制台查看 'endpoint' => 'XXXX.mqtt.aliyuncs.com',// 设置以后用户的接入点域名，接入点获取办法请参考接入筹备章节文档，先在控制台创立实例 'instanceId' => 'XXXX', //实例 ID，购买后从控制台获取 'groupId' => 'GID_XXXX',//MQTT GroupID,创立实例后从 MQTT 控制台创立 'topic'=>'XXXX', //须要操作的 Topic,第一级父级 topic 须要在控制台申请 'deviceId' => 'XXXX',//客户端惟一示意])# 获取客户端参数$mqtt->getClientInfo($deviceId)# p2p 发送音讯$mqtt->p2pPublish(deviceId, '我是测试');# 自定义发送音讯内容 $clientId 生成规定：$topic + $groupId + '@@@' + $deviceId 例如:'topic/p2p/GID_XXXX@@@00001'$mqtt->publish($clientId, '我是测试');MqttService二次封装 class MqttService{ /** * 此处填写阿里云帐号 AccessKey ID * @var */ protected $acessKeyID; /** * 此处填写阿里云帐号 AccessKey Secret * @var */ protected $accessKeySecret; /** * 接入点地址，购买实例后从控制台获取 * @var */ protected $endpoint; /** * @var int * 标准协议端口 */ protected $port = 1883; /** * @var int * SSL 端口 */ protected $sslPort = 8883; /** * @var int * WebSocket 端口 */ protected $webSocketPort = 80; /** * @var int * WebSocket SSL/TLS 端口 */ protected $webSocketSslPort = 443; /** * @var int * Flash 端口 */ protected $flashPort = 843; /** * 实例 ID，购买后从控制台获取 * @var */ protected $instanceId; /** * MQTT 客户端ID 前缀， GroupID，须要在 MQTT 控制台申请 * @var */ protected $groupId; /** * @var * 须要操作的 Topic,第一级父级 topic 须要在控制台申请 */ protected $topic; /** * MQTT 客户端ID 后缀，DeviceId，业务方自在指定，须要保障全局惟一，禁止 2 个客户端连贯应用同一个 ID * @var */ protected $deviceId; /** * @var */ protected $clientId; /** * @var bool * 如果应用 HTTPS 加密则配置为 true */ protected $useTLS = false; /** * @var int */ protected $connectTimeout = 5; /** * @var */ protected $mqtt; /** * Application constructor. * @param array $config * @throws \PhpMqtt\Client\Exceptions\ConfigurationInvalidException * @throws \PhpMqtt\Client\Exceptions\ConnectingToBrokerFailedException * @throws \PhpMqtt\Client\Exceptions\ProtocolNotSupportedException */ public function __construct(array $config = []) { parent::__construct($config); // connect $this->mqtt = $this->setMqttClient(); //close register_shutdown_function(function () { $this->disconnect(); }); } /** * @param $toDeviceId * @param $message * @return mixed * @throws \PhpMqtt\Client\Exceptions\ConfigurationInvalidException * @throws \PhpMqtt\Client\Exceptions\ConnectingToBrokerFailedException * @throws \PhpMqtt\Client\Exceptions\DataTransferException * @throws \PhpMqtt\Client\Exceptions\ProtocolNotSupportedException * @throws \PhpMqtt\Client\Exceptions\RepositoryException */ public function p2pPublish(string $toDeviceId, string $message) { $p2p_topic = $this->topic . '/p2p/' . $this->clientId($toDeviceId); return $this->publish($p2p_topic, $message); } /** * @param string $topic * @param string $message * @param int $qualityOfService * @param bool $retain * @return mixed * @throws \PhpMqtt\Client\Exceptions\ConfigurationInvalidException * @throws \PhpMqtt\Client\Exceptions\ConnectingToBrokerFailedException * @throws \PhpMqtt\Client\Exceptions\DataTransferException * @throws \PhpMqtt\Client\Exceptions\ProtocolNotSupportedException * @throws \PhpMqtt\Client\Exceptions\RepositoryException */ public function publish(string $topic, string $message, int $qualityOfService = 0, bool $retain = false) { $this->mqttClient()->publish($topic, $message, $qualityOfService, $retain); return $this->deviceId; } /** * @return array */ public function getClientInfo($deviceId) { return [ 'endpoint' => $this->endpoint, 'useTLS' => $this->useTLS, 'port' => $this->port(), 'webSocketPort' => $this->webSocketPort(), 'username' => $this->username(), 'password' => $this->password(), 'clientId' => $this->clientId($deviceId), ]; } /** * @return MqttClient * @throws \PhpMqtt\Client\Exceptions\ConfigurationInvalidException * @throws \PhpMqtt\Client\Exceptions\ConnectingToBrokerFailedException * @throws \PhpMqtt\Client\Exceptions\ProtocolNotSupportedException */ protected function setMqttClient() { $this->clientId = $this->clientId($this->deviceId); $mqtt = new MqttClient($this->endpoint, $this->port(), $this->clientId); $connectionSettings = (new ConnectionSettings()) ->setUsername($this->username()) ->setPassword($this->password()) ->setUseTls($this->useTLS) ->setConnectTimeout($this->connectTimeout); $mqtt->connect($connectionSettings, true); return $mqtt; } /** * @return MqttClient */ public function mqttClient(): MqttClient { return $this->mqtt; } /** * @param $deviceId * @return string */ public function clientId($deviceId) { return $this->groupId . '@@@' . $deviceId; } /** * @return int */ protected function port() { return $this->useTLS ? $this->sslPort : $this->port; } /** * @return int */ protected function webSocketPort() { return $this->useTLS ? $this->webSocketSslPort : $this->webSocketPort; } /** * @return string */ protected function username() { return 'Signature|' . $this->acessKeyID . '|' . $this->instanceId; } /** * @return string */ protected function password() { $hash = hash_hmac('sha1', $this->clientId, $this->acessKeyID, true); return base64_encode($hash); } /** * @throws \PhpMqtt\Client\Exceptions\DataTransferException */ protected function disconnect() { $this->mqtt->disconnect(); }}

MQTT 是轻量级的、灵便的物联网音讯替换和数据传递协定，致力于为 IoT 开发人员实现灵活性与硬件/网络资源的均衡。 ESP32 是 ESP8266 的降级版本，除了Wi-Fi模块，该模块还蕴含蓝牙4.0模块。双核CPU工作频率为80至240 MHz，蕴含两个Wi-Fi和蓝牙模块以及各种输出和输入引脚， ESP32 是物联网我的项目的现实抉择。 在此我的项目中咱们将实现 ESP32 连贯到 EMQ X MQTT Cloud 经营和保护的 收费公共 MQTT 服务器，并应用 Arduino IDE 来对 ESP32 进行编程。 EMQ X Cloud 是由 EMQ 推出的平安的 MQTT 物联网云服务平台，它提供一站式运维代管、独有隔离环境的 MQTT 5.0 接入服务。 所需物联网组件ESP32Arduino IDEMQTT 5.0 客户端工具 - MQTT X部署在 EMQ X Cloud 上的收费的公共 MQTT 服务器 Broker: broker-cn.emqx.ioTCP Port: 1883Websocket Port: 8083Arduino 配置装置 ESP32 开发板点击 工具 -> 开发板 -> 开发板治理 -> 搜寻 ESP32 -> 点击装置 ...

随着云通信行业持续增长，5G建设逐步推进、音视频技术疾速迭代，都是为了满足人与人、设施与人、设施与设施之间的音讯传输。这无疑是一个音讯传输的时代。在这个时代中，所有的协定、配置都在于恰到好处。正如MQTT音讯传输协定基于物联网，但又不局限于物联网，同样能够在挪动互联网中承当多种性能。 MQTT是一个极其轻量级的公布/订阅音讯传输协定，它解除工夫与空间耦合，能够在利用内实现推送、告诉等性能；它简洁、轻量，极小的SDK空间占用，实用于嵌入Android、iOS、RTOS等多端平台；它数据包小、功耗低，实用于低带宽、高提早或不牢靠的网络环境。 环信MQTT音讯云的产品定位就是充分发挥MQTT协定劣势，为开发者提供利用与利用之间、设施与利用之间、利用与平台之间的音讯传输服务。为了让大家更深刻理解MQTT协定劣势，环信举办本次MQTT创意挑战赛，诚邀宽广开发者通过编程实战，理论感触MQTT协定在利用间音讯传输的劣势。为了让大家更深刻理解MQTT协定劣势，环信举办本次公开课，届时，咱们将线上凝听： 环信MQTT音讯云外围性能有哪些？与IM的区别是什么？环信MQTT音讯云实时交互服务背地有哪些要害的技术劣势？环信MQTT音讯云在不同行业畛域有哪些典型的场景解决方案？环信MQTT音讯云将来关注的技术发展趋势有哪些？环信MQTT如何让开发者更为轻松的利用？环信MQTT挑战赛赛题赛制介绍20万总奖池解析7月14日，环信新产品公布直播间，邀请环信开发者经营一姐、环信MQTT产品经理、中科宏一教育团体Android主管，将围绕以上议题线上开展分享，咱们直播间不见不散！ 从MQTT技术干货分享，到利用实际，再到行业最新案例实际……更多精彩值得期待！ 点击【此处】即可报名加入。

环信MQTT云服务是基于MQTT轻量级音讯传输协定的私有云服务，反对海量连贯、抗弱网环境、多协定接入、实时监控以及音讯收发、离线音讯存储等通用消息传递性能。相较于传统IM，环信MQTT云服务更轻量级，开销小，能无效升高网络流量老本，十分实用于挪动弱网环境。同时基于公布/订阅模式的音讯传输协定能高效的向一个和多个接收者传递信息，是传统IM场景的计划补充，而非代替。 一、背景 新技术：2021年随着5G商用的疾速落地，其高牢靠、低时延和大连贯等个性将减速解锁下一代社交通信、智能硬件、物联网等多样化利用场景。物联网市场方兴未艾，依据IDC数据显示，2020年寰球物联网市场规模为1.7万亿美元。依据GSMA预测，寰球物联网连接数会从2019年的120亿增长至2025年的246亿，年复合增长率为17%。同时，2021年寰球MQTT代理服务较2020年增长40%，MQTT作为轻量级、抗弱网、易集成的音讯传输协定，将满足人与人之间、设施与人之间、设施与设施之间信令、即时消息等模式的互联网通信需要。 新局势：在寰球经济面临上行压力的背景下，云基础设施也逐步欠缺，企业更偏向于精细化经营策略，防止反复“造轮子”，相比于传统自研服务，通过与业余PaaS服务商单干，可能帮忙企业降本增效，缩短业务上线工夫，其老本和效率劣势进一步凸显。 新产品：环信作为国内即时通讯云服务的开创者，始终致力于“连贯”，包含连贯人与人、人与商业、物与物。为了实现“连贯”愿景，环信致力于打造寰球当先的音讯云(Global Message Cloud)，面向寰球开发者提供云原生音讯基础设施。环信音讯云产品矩阵包含：Easemob Chat(环信即时通讯云)、Easemob Telco(短信和5G 音讯)、Easemob Push(全平台音讯推送)，以及最新公布的Easemob MQTT。 环信MQTT云服务是基于MQTT轻量级音讯传输协定的私有云服务，反对海量连贯、抗弱网环境、多协定接入、实时监控以及音讯收发、离线音讯存储等通用消息传递性能。相较于传统IM，环信MQTT云服务更轻量级，开销小，能无效升高网络流量老本，十分实用于挪动弱网环境。同时基于公布/订阅模式的音讯传输协定能高效的向一个和多个接收者传递信息，是传统IM场景的计划补充，而非代替。 二、外围利用场景和技术个性 MQTT 全称为 Message Queuing Telemetry Transport(音讯队列遥测传输)是一种基于公布/订阅范式的“轻量级”音讯协定。环信MQTT音讯云作为一款平安、稳固、高并发、低成本的音讯代理服务产品，实用于实时数据流传输、实时地位跟踪、近程互动以及智能设施等4大外围利用场景中。 1、实时数据流传输 随着十四五数字化转型的推动，将有更多服务突破线上线下的界线。实时数据的传输成为一个可能带来体验反动的技术点。MQTT音讯云为实时音讯传输提供E2E的云服务，能够利用于股票数据的实时更新、实时拍卖中的交易信令的传输，大型线上流动的实时弹幕展现等。 面向该场景环信MQTT音讯云服务提供如下技术个性： SLA 99.9%以上云服务集群保障 反对大量数据流的实时传输 轻松构建实时显示和数据驱动的体验 2、实时地位跟踪 实时地位共享曾经从出行的场景逐步利用于社交、外卖等多种场景。MQTT音讯云实时地位性能针对不同的场景反对3种级别的QoS传输，保障弱网及挪动传输网络传输稳定性，能够利用于实时航班跟踪、外卖送餐间隔、物流跟踪等地位共享场景。 面向该场景环信MQTT音讯云服务提供如下技术个性： 反对 QoS0、QoS1与 QoS2 级别 MQTT 音讯 保障弱网环境音讯传输稳定性 反对地位数据实时共享 3、近程互动 随着挪动互联网的倒退，在线教育、游戏、浏览等利用体验正在产生粗浅的改革，互动化、社交化已成为产品营销的外围能力。MQTT音讯云提供安卓、IOS等多种支流的SDK，反对客户疾速在利用中集成MQTT服务，构建多端用户共享空间，能够利用于在线教育白板、你猜我画、云观影等互动场景。 面向该场景环信MQTT音讯云服务提供如下技术个性： 反对规范的MQTT V3.0及MQTT V5.0音讯协定 反对接入Java、IOS、Android等多种版本MQTT客户端 ...

前言最近工作中有用到MQTT 协定，在此做一个钻研学习总结和采坑指南。如果你在工作中也有用到，欢送交换。文中如有不足之处，欢送斧正。1. 什么是MQTTMQTT（Message Queuing Telemetry Transport，音讯队列遥测传输协定），是一种基于公布/订阅（publish/subscribe）模式的轻量级协定，该协定构建于TCP/IP协定之上，MQTT最大长处在于，能够以极少的代码和无限的带宽，为连贯近程设施提供实时牢靠的音讯服务。作为一种低开销、低带宽占用的即时通讯协定，使其在物联网、小型设施、挪动利用等方面有较宽泛的利用。 MQTT是一个基于客户端-服务器的音讯公布/订阅传输协定。MQTT协定是轻量、简略、凋谢和易于实现的，这些特点使它适用范围十分宽泛。在很多状况下，包含受限的环境中，如：机器与机器（M2M）通信和物联网（IoT）。其在，通过卫星链路通信传感器、偶然拨号的医疗设施、智能家居、及一些小型化设施中已宽泛应用。　小结：MQTT 曾经成为物联网零碎事实上的网络协议规范。如果你想从事物联网开发，就肯定要把握 MQTT。 2. 感触MQTT的应用装置 MQTT，能够间接找到 hbmqtt （python语言）这样的我的项目拿来用。它的背地有 Eclipse 基金会的反对。 相似的 MQTT Broker 软件，你还能够抉择基于 C 语言的Mosquitto，基于 Erlang 语言的VerneMQ等。 至于 MQTT 的客户端（Client）实现，也有成熟的 Python、C、Java 和 JavaScript 等各种编程语言的开源实现，供你参考、应用，比方Eclipse Paho 我的项目。 而且，还有很多商业公司在继续经营性能更丰盛、反对更齐备的商业版 Broker 实现，比方提供高并发能力的集群个性、不便拓展的插件机制等。这些会大大提高咱们技术开发者的工作效率。比方中国一个团队开发、保护的 EMQ X，它曾经残缺地反对 MQTT5.0 协定。 测试工具举荐：MQTT X 能够在线测试或下载本地客户端进行mqtt连贯测试和事件的主题订阅、音讯发送等。 有助于定位问题，强烈推荐。 另外，生态欠缺还有一个益处，那就是作为开发者，当你遇到难题时，能够很不便地找到很多相干的材料；就算材料解决不了问题，你还能够去社区中发问，寻求高手的帮忙。这在理论工作中十分有用。顺便提一下，除了老牌的 Stack Overflow，你还能够关注一下 GitHub 的 Issues 模块，因为在那里能够找到很多专家。 小结：做为Android开发者，我曾经找出了泛滥开源我的项目的官网开源地址，如想疾速体验，请移步： Android Service 在采坑中发现，有些问题是存在的，比方Andorid Q之后的前台服务等问题，有些fork分支解决了局部问题，如果你在我的项目中也遇到了类似问题，先看看issus中的解决方案，甚至能够间接应用fork分支上的开源我的项目。 小结：mqttt 应用上手是十分快的，测试和工具应用能够很快感觉mqtt的流程，体验后能够依据我的项目的技术指标在钻研下第三方如阿里云mqtt本人搭建服务器时性能指标。而后再依据业务需要，抉择第三方平台和本人搭建服务器。 3. MQTT的生态绝对欠缺当然，阿里云、华为云、腾讯云和微软 Azure 这些大厂，之所以不谋而合地抉择 MQTT 协定作为物联网设施的“第一语言”，不仅是因为 MQTT 的生态欠缺，MQTT 协定自身的优良设计也是重要的因素。 它在设计上的长处体现在哪呢？我想次要有五个方面： ...

MQTT X 是由寰球当先的开源物联网中间件提供商 EMQ 开源的一款跨平台 MQTT 5.0 桌面测试客户端，它反对 macOS，Linux，Windows。MQTT X 的用户界面借助聊天软件的模式简化了页面的操作逻辑，用户能够疾速创立多个同时在线的 MQTT 客户端，不便测试 MQTT/TCP、MQTT/TLS、MQTT/WebSocket 的连贯/公布/订阅性能及其他 MQTT 协定 个性。 MQTT X 网站：https://mqttx.app/cn/ MQTT X v1.4.1 版本下载：https://github.com/emqx/MQTTX... Mac 用户可在 App Store 中进行下载：https://apps.apple.com/cn/app... Linux 用户可在 Snapcraft 中进行下载：https://snapcraft.io/mqttx 新性能概览收发流量统计（目前仅反对 EMQ X） 此性能可通过点击右上角的下来菜单，抉择流量统计，MQTT X 会主动订阅零碎主题，并能够在页面中展现该 Broker 下的简略的流量统计图表，运行版本和运行工夫。 留神：应用该性能时，可能会呈现订阅零碎主题失败的谬误，此时可能是因为 EMQ X 默认只容许本机的 MQTT 客户端订阅 $SYS 主题，或请参照 内置 ACL 批改公布订阅 ACL 规定。 反对定时发送 Payload此性能可通过点击右上角的下拉菜单，抉择定时音讯，这时会关上设置弹窗，用户只需填写发送音讯的工夫频率，单位为秒。设置胜利后填写发送所须要的 Topic 和 Payload 等，手动点击发送一条音讯后，即可胜利关上定时音讯性能，这时音讯可按用户设置的工夫频率进行定时发送。如需勾销定时，可点击顶部栏中，断开连接按钮旁的时钟按钮，即可勾销定时。 反对显示以后连贯的音讯数当连贯胜利后，左上角的连贯名称旁，将显示以后连贯所有的收发音讯数，当鼠标悬浮到该数字上时，还能够看到发送和接管到的音讯数别离是多少。 增加关上新窗口的快捷键在之前的版本中，关上连贯的新窗口，须要右键点击连贯，应用右键菜单性能能力关上新窗口，较为荫蔽且操作繁琐，该版本优化了此性能的交互，在每个连贯的顶部栏中，下拉菜单按钮左侧新增了一个新建窗口按钮，当用户须要应用新窗口时，只须要点击该按钮即可。 ...

拉取镜像docker pull vernemq/vernemq 启动容器docker run -p 21883:1883 -p 28888:8888 --name vernemq1 -dit vernemq/vernemq /bin/bash 进入容器是指定为root用户，以便装置编辑器更改外部配置docker exec -it -u root vernemq1 /bin/bash 21883为宿主机mqtt连贯端口 2888为http相干协定接口，restapi等都是拜访此接口。 更多mqtt相干文章请关注 http://www.evenvi.com/index.p...

什么是会话？咱们将从客户端向服务端发动 MQTT 连贯申请开始，到连贯中断直到会话过期为止的音讯收发序列称之为会话。因而，会话可能仅继续一个网络连接，也可能逾越多个网络连接存在，如果客户端能在会话过期之前从新建设了连贯的话。 在 MQTT v5 中会话过期工夫由 Session Expiry Interval 字段决定，早前版本的协定没有限度会话过期工夫，但通常由 MQTT 服务端决定。什么是会话状态？MQTT 要求客户端与服务端在会话有效期内存储一系列与客户端标识相关联的状态，称之为会话状态。 客户端须要存储以下会话状态： 已发送给服务端，然而还没有实现确认的 QoS 1 与 QoS 2 音讯。从服务端收到的，然而还没有实现确认的 QoS 2 音讯。服务端须要存储以下会话状态： 会话是否存在，即便会话状态其余部分为空。客户端订阅信息，包含任何订阅标识符。已发送给客户端，然而还没有实现确认的 QoS 1 与 QoS 2 音讯。期待传输给客户端的 QoS 0 音讯（可选），QoS 1 与 QoS 2 音讯。从客户端收到的，然而还没有实现确认的 QoS 2 音讯，遗嘱音讯和遗嘱延时距离。会话过期工夫。会话状态的应用如果客户端因为网络稳定等起因导致连贯短暂中断，但在会话过期前从新与服务端建设了连贯，那么就能够沿用上次连贯建设的订阅关系，不须要从新订阅一遍。在低带宽、不稳固的网络场景下，网络中断可能会产生得很频繁，保留会话状态的形式防止了每次连贯都须要从新订阅，升高了重连时客户端和服务端的资源耗费。服务端在客户端脱机期间为其保留未实现确认的以及后续达到的音讯，客户端从新连贯时再一并转发，既能够防止音讯失落，也可能升高某些场景下用户对网络变动的感知度。 会话的开始与完结MQTT v5.0 与 v3.1.1 在会话上有着较为显著的变动。MQTT v3.1.1 只有一个 Clean Session 字段，由客户端在连贯时指定，为 1 示意客户端和服务器必须抛弃任何先前的会话并创立一个新的会话，且这个会话的生命周期与网络连接保持一致；为 0 则示意服务端必须应用与 Client ID 关联的会话来复原与客户端的通信（除非会话不存在），客户端和服务器在断开连接后必须存储会话的状态。 MQTT v3.1.1 没有规定长久会话应该在什么时候过期，如果仅从协定层面了解的话，这个长久会话应该永恒存在。但在理论场景中这并不事实，因为它会十分占用服务端的资源，所以服务端通常不会遵循协定来实现，而是向用户提供一个全局配置来限度会话过期工夫。 而到了 MQTT 5.0，这个问题失去了妥善的解决，Clean Session 字段被拆分成了 Clean Start 字段与 Session Expiry Interval 字段。Clean Start 字段指定是否须要全新的会话，Session Expiry Interval 字段指定会话过期工夫，它们在连贯时指定，但 Session Expiry Interval 字段能够在客户端断开连接时被更新。因而咱们能够很轻易地实现客户端网络连接异样断开时会话被保留，客户端失常下线时会话则随着连贯敞开而终结的性能。 ...

MQTT v5 带来了很多新的个性，咱们会尽量以通俗易懂的形式展现这些个性，并探讨这些个性对开发者的影响。到目前为止，咱们曾经探讨过这些 MQTT v5 新个性，明天咱们将持续探讨：订阅标识符 和 订阅选项。 订阅标识符客户端能够在订阅时指定一个订阅标识符，服务端将在订阅胜利创立或批改时建设并存储该订阅与订阅标识符的映射关系。当有匹配该订阅的 PUBLISH 报文要转发给此客户端时，服务端会将与该订阅关联的订阅标识符随 PUBLISH 报文一并返回给客户端。 因而，客户端能够建设订阅标识符与音讯处理程序的映射，以在收到 PUBLISH 报文时间接通过订阅标识符将音讯定向至对应的音讯处理程序，这会远远快于通过主题匹配来查找音讯处理程序的速度。 因为 SUBSCRIBE 报文反对蕴含多个订阅，因而可能呈现多个订阅关联到同一个订阅标识符的状况。即使是离开订阅，也可能呈现这种状况，但这是被容许的，只是用户该当意识到这样应用可能引起的结果。依据客户端的理论订阅状况，最终客户端收到的 PUBLISH 报文中可能蕴含多个订阅标识符，这些标识符可能齐全不同，也可能有些是雷同的，以下是几种常见的状况： 客户端订阅主题 a 并指定订阅标识符为 1，订阅主题 b 并指定订阅标识符为 2。因为应用了不同的订阅标识符，主题为 a 和 b 的音讯可能被定向至不同的音讯处理程序。客户端订阅主题 a 并指定订阅标识符为 1，订阅主题 b 并指定订阅标识符为 1。因为应用了雷同的订阅标识符，主题为 a 和 b 的音讯都将被定向至同一个音讯处理程序。客户端订阅主题 a/+ 并指定订阅标识符为 1，订阅主题a/b 并指定订阅标识符为 1。主题为 a/b 的 PUBLISH 报文将会携带两个雷同的订阅标识符，对应的音讯处理程序将被触发两次。客户端订阅主题 a/+ 并指定订阅标识符为 1，订阅主题a/b 并指定订阅标识符为 2。主题为 a/b 的 PUBLISH 报文将会携带两个不同的订阅标识符，一个音讯将触发两个不同的音讯处理程序。 这种 PUBLISH 报文中携带多个订阅标识符的状况，在音讯速率低的时候通常不成问题，但在音讯速率高时可能会引发一些性能问题，因而咱们建议您尽量确保这种状况的呈现都是您无意为之。 订阅选项在 MQTT v5 中，你能够应用更多的订阅选项来扭转服务端的行为。 ...

作为基于古代密码学公钥算法的平安协定，TLS/SSL 能在计算机通信网络上保障传输平安，EMQ X 内置对 TLS/SSL 的反对，包含反对单/双向认证、X.509 证书、负载平衡 SSL 等多种平安认证。你能够为 EMQ X 反对的所有协定启用 SSL/TLS，也能够将 EMQ X 提供的 HTTP API 配置为应用 TLS。 在上一片篇文章中，咱们曾经介绍过如何为 EMQ X MQTT 服务器启用 SSL/TLS 单向平安连贯，本文将介绍如何在 EMQ X 中为 MQTT 启用双向 SSL/TLS 平安连贯。 SSL/TLS 带来的平安劣势强认证。 用 TLS 建设连贯的时候，通信单方能够相互查看对方的身份。在实践中，很常见的一种身份查看形式是查看对方持有的 X.509 数字证书。这样的数字证书通常是由一个受信机构颁发的，不可伪造。保障机密性。TLS 通信的每次会话都会由会话密钥加密，会话密钥由通信单方协商产生。任何第三方都无奈通晓通信内容。即便一次会话的密钥泄露，并不影响其余会话的安全性。完整性。 加密通信中的数据很难被篡改而不被发现。SSL/TLS 协定TLS/SSL 协定下的通信过程分为两局部，第一局部是握手协定。握手协定的目标是甄别对方身份并建设一个平安的通信通道。握手实现之后单方会协商出接下来应用的明码套件和会话密钥；第二局部是 record 协定，record 和其余数据传输协定十分相似，会携带内容类型，版本，长度和荷载等信息，不同的是它所携带的信息是加密了的。 上面的图片形容了 TLS/SSL 握手协定的过程，从客户端的 "hello" 始终到服务器的 "finished" 实现握手。有趣味的同学能够找更具体的材料看。对这个过程不理解也并不影响咱们在 EMQ X 中启用这个性能。 为什么须要 SSL/TLS 双向认证双向认证是指，在进行通信认证时要求服务端和客户端都须要证书，单方都要进行身份认证，以确保通信中波及的单方都是受信赖的。 单方彼此共享其公共证书，而后基于该证书执行验证、确认。一些对安全性要求较高的利用场景，就须要开启双向 SSL/TLS 认证。 SSL/TLS 证书筹备在双向认证中，个别都应用自签名证书的形式来生成服务端和客户端证书，因而本文就以自签名证书为例。 ...

随着 5G 时代的来临，万物互联的伟大构想正在成为现实。联网的 物联网设备 在 2018 年已经达到了 70 亿1，在未来两年，仅智能水电气表就将超过10亿2。 海量的设备接入和设备管理对网络带宽、通信协议以及平台服务架构都带来了很大挑战。对于 物联网协议 来说，必须针对性地解决物联网设备通信的几个关键问题：其网络环境复杂而不可靠、其内存和闪存容量小、其处理器能力有限。 MQTT 协议 是基于发布/订阅模式的物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山： MQTT 协议的诞生MQTT was created by Andy Stanford-Clark of IBM, and Arlen Nipper (then of Arcom Systems, later CTO of Eurotech).3 据 Arlen Nipper 在一 IBM Podcast 上的自述，MQTT 原名是 MQ TT， 注意 MQ 与 TT 之间的空格，其全称为: MQ Telemetry Transport，是九十年代早期，他在参与 Conoco Phillips 公司的一个原油管道数据采集监控系统(pipeline SCADA system)时，开发的一个实时数据传输协议。它的目的在于让传感器通过带宽有限的 VSAT ，与 IBM 的 MQ Integrator 通信。由于 Nipper 是遥感和数据采集监控专业出身，所以按业内惯例给了个 MQ TT 的名字。 ...

OpenTSDB 介绍OpenTSDB 是可扩展的分布式时序数据库，底层依赖 HBase 并充分发挥了HBase的分布式列存储特性，支持数百万每秒的读写。 面对大规模快速增长的物联网传感器采集、交易记录等数据，时间序列数据累计速度非常快，时序数据库通过提高效率来处理这种大规模数据，并带来性能的提升，包括：更高的容纳率（Ingest Rates）、更快的大规模查询以及更好的数据压缩。 安装与验证 OpenTSDB 服务器读者可以参考 OpenTSDB 官方文档 (http://opentsdb.net) 或 Docker (https://hub.docker.com/r/pete... 来下载安装 OpenTSDB 服务器，本文使用 OpenTSDB 2.4.0 版本。 场景介绍该场景需要将 EMQ X 指定主题下且满足条件的消息存储到 OpenTSDB 数据库。为了便于后续分析检索，消息内容需要进行拆分存储。 该场景下客户端上报数据如下： Topic：stat/cpuPayload: { "metric": "cpu", "tags": { "host": "serverA" }, "value":12}准备工作启动 OpenTSDB Server启动 OpenTSDB Server 并开放 4242 端口。 $ docker pull petergrace/opentsdb-docker$ docker run -d --name opentsdb -p 4242:4242 petergrace/opentsdb-docker配置说明创建资源打开 EMQ X Dashboard，进入左侧菜单的 资源 页面，点击 新建 按钮，选择 OpenTSDB 资源类型并完成相关配置进行资源创建。 ...

前言最近入手了一台斐讯K3路由器,可是博通的芯片发热太严重,想要随时了解路由器的温度,于是自己动手实现了一组程序来将路由器温度通过MQTT加入Homeassistant及Homekit. 准备已经获取root权限的K3路由器部署好HomeAssistant的内网服务器部署好Node.js的内网服务器前置知识基本的Shell编程基本的HTTP及web服务器知识基本的MQTT原理基础JavaScript编程软件结构最早的想法是直接在路由器上通过Python获取数据及通过MQTT发送至HASS服务器,但是一个是opkg的源太慢了,另一个是不想给路由器增加额外负担(万一加了测温软件温度涨几度就尴尬了),最终采用了如下的软件结构 路由器---> Node.js Server ---> Homeassistant其中路由器到Node.js通过简单的HTTP,将温度数据通过JSON发送过来.Node.js通过Express.js实现web服务器用于接受路由器数据,mqtt包实现mqtt通讯,发送给Homeassistant. 服务器端Shell程序温度获取首先第一步是获取路由器的温度数据: CPUcat /proc/dmu/temperature #CPU温度wl -i eth1 phy_tempsense #2.4GHz无线芯片温度wl -i eth2 phy_tempsense #5GHz无线芯片温度运行结果如下: 需要注意的是这里有一个坑,CPU温度的文件中又不符合UTF-8的字符,直接用curl发的话会导致错误,这里我们直接用cut进行处理,这里暂时不考虑温度为或3位的情况(事实上不太可能发生)cat /proc/dmu/temperature|cut -c19-20同理我们对另外两项数据也进行处理 wl -i eth1 phy_tempsense|cut -c0-2wl -i eth2 phy_tempsense|cut -c0-2发送温度数据HTTP数据约定GET Method数据位于data参数下,内容封装于JSON中,格式如下{"type":"data","CPU":61,"W24G":51,"W5G":65} curl实现这里我们通过curl来发送数据,这里是用GET方法,为了以后增加控制信息方便,数据包格式如下 {"type":"data","CPU":61,"W24G":51,"W5G":65}经过url encode的结果为 %7B%22type%22:%22data%22,%22CPU%22:61,%22W24G%22:51,%22W5G%22:65%7D我的Node.js服务器地址是192.168.2.103,端口3000所以我们的url是 url="http://192.168.2.103:3000/?data=%7B%22type%22:%22data%22,%22CPU%22:$cpu,%22W24G%22:$w24,%22W5G%22:$w5%7D"增加无限循环后的完整程序#!/bin/shecho " run.. "while truedo cpu=$(cat /proc/dmu/temperature|cut -c19-20) w24=$(wl -i eth1 phy_tempsense|cut -c0-2) w5=$(wl -i eth2 phy_tempsense|cut -c0-2) url="http://192.168.2.103:3000/?data=%7B%22type%22:%22data%22,%22CPU%22:$cpu,%22W24G%22:$w24,%22W5G%22:$w5%7D" curl $url sleep 60 #设置1分钟的查询周期 continuedoneecho " end.. "为了让程序不断运行,推荐用screen来管理Node端程序HTTP服务器这里我们基本使用了模版提供的功能,由于我们这里只对数据进行透明传输,所以JSON不需要反序列化 router.get('/', function(req, res, next) { var data = req.query.data res.render('index', { title: 'Express' });});MQTT客户端MQTT数据约定我们的数据分别放在三个Topic下 ...

本章节我们将学习如何使用MQ库. MQ库简介MQ库实现了各类消息代理中间件(Message Broker)的连接协议, 目前支持:redis、mqtt、stomp协议. MQ库基于上述协议实现了: 生产者 -> 消费者与订阅 -> 发布模型, 可以在不依赖其它服务的情况下独立完成任务. API介绍cf框架提供了多种MQ的封装, 当我们需要使用的时候需要根据实际的协议进行选择: -- local MQ = require "MQ.mqtt"-- local MQ = require "MQ.redis"-- local MQ = require "MQ.stomp"MQ:new(opt)此方法将会创建一个的MQ对象实例. opt是一个table类型的参数, 可以传递如下值: host - 字符串类型, 消息队列的域名或者IP地址.port - int类型, 消息队列监听的端口.auth/db - 字符串类型, 仅在redis协议下用作登录认证或者db选择(没有可以不填写).username/password - 字符串类型, 仅在stomp/mqtt协议下用作登录认证(没有可以不填写).vhost - 字符串类型, 仅在使用某些特定消息队列server的时候填写(例如:rabbit).keepalive - int类型, 仅在使用mqtt的时候用来出发客户端主动发出心跳包的时间.以redis broker为示例: local MQ = require "MQ.redis"local mq = MQ:new { host = "localhost", port = 6379, -- db = 0, -- auth = "123456789",}MQ:on(pattern, function)此方法用来订阅一个指定pattern. 当broker将消息传递到cf后, function将会被调用. ...

前言建议先阅读：在Node.js下运用MQTT协议实现即时通讯及离线推送以前尝试在vue中用上mqtt，了解到mqtt实质上是基于websocket进行数据通信，所以上文中在node下实现的服务端此时不能满足需求代码服务端: server.jslet http = require(‘http’), httpServer = http.createServer(), mosca = require(‘mosca’)let settings = { port: 5112, persistence:{ factory: mosca.persistence.Mongo, url: “mongodb://localhost:27017/mosca” }}let server = new mosca.Server(settings)server.attachHttpServer(httpServer)server.on(‘published’, function(packet, client) { console.log(‘Published’, packet.payload.toString());})httpServer.listen(3003)server.on(‘ready’, function(){ console.log(‘server is running at port 3003’); })服务端mosca的实例化并没有改动而是将其为websocket形式进行适配客户端: mqtt.jslet mqtt = require(‘mqtt’)let client = {}export default { launch(id, callback) { client = mqtt(‘mqtt://ip’, { port: 3003, clientId: id, clean: false }) client.on(‘message’, (topic, message) => { callback(topic, message) }) }, end() { client.end() }, subscribe(topic) { client.subscribe(topic, {qos: 1}) console.log(‘subscribe:’, topic) }, publish(topic, message) { client.publish(topic, JSON.stringify(message), {qos: 1}) }}独立地对mqtt进行简单地封装，方便调用值得注意的是此时的协议头仍为mqtt，但mqtt源码会以ws形式进行通信main.js:再把mqtt绑到vue原型链上import mqtt from ‘./api/mqtt’Vue.prototype.$mqtt = mqtt现在便可在vue环境中对mqtt进行调用this.$mqtt.launch(this.user._id, (topic, source) => { console.log(‘message: ‘, JSON.parse(source.toString()))})转载请注明出处 ; ) ...

前言前些日子了解到mqtt这样一个协议，可以在web上达到即时通讯的效果，但网上并不能很方便地找到一篇目前版本的在node下正确实现这个协议的博客。自己捣鼓了一段时间，理解不深刻，但也算是基本能够达到使用目的。本文尚未对离线消息的接收顺序进行处理。代码服务端: server.js//服务端引入中间件moscalet mosca = require(‘mosca’)let settings = { port: 5112}let server = new mosca.Server(settings)server.on(‘ready’, function(){ console.log(‘Mosca server is up and running at port 5112’); })server.on(‘published’, function(packet, client) { console.log(‘Published’, packet.payload)})server.on(‘clientDisconnected’, function(client){ console.log(‘disconnected: ‘, client.id)})推送端: pub.js//客户端引入mqttlet mqtt = require(‘mqtt’);let client = mqtt.connect(‘mqtt://localhost’, { port: 5112, clientId: ‘cli_pub’,})let num = 0;setInterval(function (){ client.publish(’test’, ‘Hello mqtt ’ + (++num), {qos:1}, () => console.log(num));}, 1000)订阅端: sub.jslet mqtt = require(‘mqtt’)let client = mqtt.connect(‘mqtt://localhost’, { port: 5112, clientId: ‘cli_sub’,})client.subscribe(’test’,{qos:1})client.on(‘message’, function (topic, message) { console.log(‘received message: ‘, message.toString())})server运行后，先启动pub，再启动sub，即可在sub中接收到推送过来的消息序列至此实现了简单的即时推送离线推送相关配置及简要介绍离线配置-服务端：要实现消息的离线推送，必然需要一个存储临时数据的部件此处用到的是mongo，当然可以根据需要选择其他的存储工具server.js中的settings需更改为:let settings = { port: 5112, persistence:{ //增加了此项 factory: mosca.persistence.Mongo, url: “mongodb://localhost:27017/mosca” }}factory: 引入mosca对特定存储工具的一些处理方法url: 其中的 27017 为mongo所监听的端口号，mosca为存储相关数据的数据库值得一提的是：配置好mongo的环境后，不需要提前在mongo中手动创建，若数据库不存在会自动生成，而且mosca会为你作好其他一切基本事项 (即：若只想临时体验下效果，甚至可以暂时把mongo放一边 ) 在mongo中，可以看到自动新添了db: mosca及其下的collection(相当于关系型数据库中的表/关系)离线配置-客户端：pub.js和sub.js中的client中都可以改为：let client = mqtt.connect(‘mqtt://localhost’, { port: 5112, clientId: ‘cli_**’, clean: false//增加了此项})clientId: 区分客户端的识别码clean: 此处决定了客户端在服务端的session是否会被清除，默认为true，为实现离线推送，我们需要将其保留clean及上文中的persistence为实现离线推送的关键配置mqtt.connect()会返回一个mqttClient对象，包含了：reconnect(), subscribe(), publish()等一系列方法。本文中发送端接收端被分为了pub.js和sub.js两个独立文件，仅仅为了方便在不同控制台中观察效果一个client可以既为推送端，又为订阅端至此，所有代码已完成其他介绍：client.subscribe():为本客户端订阅一个话题，所有订阅此话题的用户都会收到在此话题下推送的信息//client.subscribe(topic,opts)client.subscribe(’test’,{qos:1})opts中的qos为通信机制，控制发送端与接收端的互锁程度上文中的其中一个collection: subscriptions即记录各用户话题订阅情况用户cli_sub及cli2_sub订阅了话题test:(新增一个cli2_pub，下文有用)注：重复执行脚本sub.js实际上对topic进行了重复订阅实际编码时，应避免topic的重复订阅，即使重复订阅并不影响实现效果client.publish():向指定topic发送数据message为Buffer或String格式，可以通过序列化或转json实现对复杂数据对象的传送//client.publish(topic, message, opts, callback)let num = 0;setInterval(function (){ client.publish(’test’, ‘Hello mqtt ’ + (++num), {qos:1}, () => console.log(num));}, 1000)参数不再赘述此处用一个定时器定时在 topic: test 下发送’Hello mqtt 1,2,3..‘用回调函数实时打印一下发送的num：当订阅者处于离线状态时，可以在collection: packets中查看到临时数据的存储情况：mosca把每一条推送消息为所有订阅用户都生成了独立的记录，用同一个messageId进行关联当其中一个用户(cli2_sub)上线时，获取到其对应的数据，而后数据库中相应记录便会被删除此时仅有cli_sub用户的数据当cli2_sub上线接收消息后，packets中记录将被清空client.on():即在client上触发的事件，此处只列举消息接收事件//client.on(event, callback)client.on(‘message’, function (topic, message) { console.log(‘received message: ‘, message.toString())})处理为简单地打印到控制台附mosca.js文档：https://www.npmjs.com/package…mqtt.js文档：https://www.npmjs.com/package…windows环境下mongo的配置：https://jingyan.baidu.com/art…及一位前辈的文章：https://www.jianshu.com/p/831…转载请注明出处 ; ) ...

SpringBoot集成MQTTMQTTMQTT（消息队列遥测传输）是ISO标准（ISO/IEC PRF 20922）下基于发布/订阅范式的消息协议。它工作在 TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议。国内很多企业都广泛使用MQTT作为Android手机客户端与服务器端推送消息的协议。特点MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合；对负载内容屏蔽的消息传输；使用TCP/IP提供网络连接；有三种消息发布服务质量；至多一次：消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。至少一次：确保消息到达，但消息重复可能会发生。只有一次：确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；使用Last Will和Testament特性通知有关各方客户端异常中断的机制。Apache-ApolloApache Apollo是一个代理服务器，其是在ActiveMQ基础上发展而来的，可以支持STOMP, AMQP, MQTT, Openwire, SSL, WebSockets 等多种协议。 原理：服务器端创建一个唯一订阅号，发送者可以向这个订阅号中发东西，然后接受者（即订阅了这个订阅号的人）都会收到这个订阅号发出来的消息。以此来完成消息的推送。服务器其实是一个消息中转站。下载下载地址：http://activemq.apache.org/ap…配置与启动需要安装JDK环境在命令行模式下进入bin，执行apollo create mybroker d:\apache-apollo\broker，创建一个名为mybroker虚拟主机（Virtual Host）。需要特别注意的是，生成的目录就是以后真正启动程序的位置。在命令行模式下进入d:\apache-apollo\broker\bin，执行apollo-broker run，也可以用apollo-broker-service.exe配置服务。访问http://127.0.0.1:61680打开web管理界面。（密码查看broker/etc/users.properties）启动端口，看cmd输出。SpringBoot2的开发添加依赖<!– spring-boot版本 2.1.0.RELEASE–><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-integration</artifactId></dependency><dependency> <groupId>org.springframework.integration</groupId> <artifactId>spring-integration-stream</artifactId></dependency><dependency> <groupId>org.springframework.integration</groupId> <artifactId>spring-integration-mqtt</artifactId></dependency>自定义配置# src/main/resources/config/mqtt.properties################### MQTT 配置################### 用户名mqtt.username=admin# 密码mqtt.password=password# 推送信息的连接地址，如果有多个，用逗号隔开，如：tcp://127.0.0.1:61613,tcp://192.168.1.61:61613mqtt.url=tcp://127.0.0.1:61613################### MQTT 生产者################### 连接服务器默认客户端IDmqtt.producer.clientId=mqttProducer# 默认的推送主题，实际可在调用接口时指定mqtt.producer.defaultTopic=topic1################### MQTT 消费者################### 连接服务器默认客户端IDmqtt.consumer.clientId=mqttConsumer# 默认的接收主题，可以订阅多个Topic，逗号分隔mqtt.consumer.defaultTopic=topic1配置MQTT发布和订阅import org.apache.commons.lang3.StringUtils;import org.eclipse.paho.client.mqttv3.MqttConnectOptions;import org.slf4j.Logger;import org.slf4j.LoggerFactory;import org.springframework.beans.factory.annotation.Value;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.integration.annotation.ServiceActivator;import org.springframework.integration.channel.DirectChannel;import org.springframework.integration.core.MessageProducer;import org.springframework.integration.mqtt.core.DefaultMqttPahoClientFactory;import org.springframework.integration.mqtt.core.MqttPahoClientFactory;import org.springframework.integration.mqtt.inbound.MqttPahoMessageDrivenChannelAdapter;import org.springframework.integration.mqtt.outbound.MqttPahoMessageHandler;import org.springframework.integration.mqtt.support.DefaultPahoMessageConverter;import org.springframework.messaging.Message;import org.springframework.messaging.MessageChannel;import org.springframework.messaging.MessageHandler;import org.springframework.messaging.MessagingException;/** * MQTT配置，生产者 * * @author BBF /@Configurationpublic class MqttConfig { private static final Logger LOGGER = LoggerFactory.getLogger(MqttConfig.class); private static final byte[] WILL_DATA; static { WILL_DATA = “offline”.getBytes(); } /* * 订阅的bean名称 / public static final String CHANNEL_NAME_IN = “mqttInboundChannel”; /* * 发布的bean名称 / public static final String CHANNEL_NAME_OUT = “mqttOutboundChannel”; @Value("${mqtt.username}") private String username; @Value("${mqtt.password}") private String password; @Value("${mqtt.url}") private String url; @Value("${mqtt.producer.clientId}") private String producerClientId; @Value("${mqtt.producer.defaultTopic}") private String producerDefaultTopic; @Value("${mqtt.consumer.clientId}") private String consumerClientId; @Value("${mqtt.consumer.defaultTopic}") private String consumerDefaultTopic; /* * MQTT连接器选项 * * @return {@link org.eclipse.paho.client.mqttv3.MqttConnectOptions} / @Bean public MqttConnectOptions getMqttConnectOptions() { MqttConnectOptions options = new MqttConnectOptions(); // 设置是否清空session,这里如果设置为false表示服务器会保留客户端的连接记录， // 这里设置为true表示每次连接到服务器都以新的身份连接 options.setCleanSession(true); // 设置连接的用户名 options.setUserName(username); // 设置连接的密码 options.setPassword(password.toCharArray()); options.setServerURIs(StringUtils.split(url, “,”)); // 设置超时时间 单位为秒 options.setConnectionTimeout(10); // 设置会话心跳时间 单位为秒 服务器会每隔1.520秒的时间向客户端发送心跳判断客户端是否在线，但这个方法并没有重连的机制 options.setKeepAliveInterval(20); // 设置“遗嘱”消息的话题，若客户端与服务器之间的连接意外中断，服务器将发布客户端的“遗嘱”消息。 options.setWill(“willTopic”, WILL_DATA, 2, false); return options; } /** * MQTT客户端 * * @return {@link org.springframework.integration.mqtt.core.MqttPahoClientFactory} / @Bean public MqttPahoClientFactory mqttClientFactory() { DefaultMqttPahoClientFactory factory = new DefaultMqttPahoClientFactory(); factory.setConnectionOptions(getMqttConnectOptions()); return factory; } /* * MQTT信息通道（生产者） * * @return {@link org.springframework.messaging.MessageChannel} / @Bean(name = CHANNEL_NAME_OUT) public MessageChannel mqttOutboundChannel() { return new DirectChannel(); } /* * MQTT消息处理器（生产者） * * @return {@link org.springframework.messaging.MessageHandler} / @Bean @ServiceActivator(inputChannel = CHANNEL_NAME_OUT) public MessageHandler mqttOutbound() { MqttPahoMessageHandler messageHandler = new MqttPahoMessageHandler( producerClientId, mqttClientFactory()); messageHandler.setAsync(true); messageHandler.setDefaultTopic(producerDefaultTopic); return messageHandler; } /* * MQTT消息订阅绑定（消费者） * * @return {@link org.springframework.integration.core.MessageProducer} / @Bean public MessageProducer inbound() { // 可以同时消费（订阅）多个Topic MqttPahoMessageDrivenChannelAdapter adapter = new MqttPahoMessageDrivenChannelAdapter( consumerClientId, mqttClientFactory(), StringUtils.split(consumerDefaultTopic, “,”)); adapter.setCompletionTimeout(5000); adapter.setConverter(new DefaultPahoMessageConverter()); adapter.setQos(1); // 设置订阅通道 adapter.setOutputChannel(mqttInboundChannel()); return adapter; } /* * MQTT信息通道（消费者） * * @return {@link org.springframework.messaging.MessageChannel} / @Bean(name = CHANNEL_NAME_IN) public MessageChannel mqttInboundChannel() { return new DirectChannel(); } /* * MQTT消息处理器（消费者） * * @return {@link org.springframework.messaging.MessageHandler} / @Bean @ServiceActivator(inputChannel = CHANNEL_NAME_IN) public MessageHandler handler() { return new MessageHandler() { @Override public void handleMessage(Message<?> message) throws MessagingException { LOGGER.error("===================={}============", message.getPayload()); } }; }}消息发布器import org.springframework.integration.annotation.MessagingGateway;import org.springframework.integration.mqtt.support.MqttHeaders;import org.springframework.messaging.handler.annotation.Header;import org.springframework.stereotype.Component;/* * MQTT生产者消息发送接口 * <p>MessagingGateway要指定生产者的通道名称</p> * @author BBF /@Component@MessagingGateway(defaultRequestChannel = MqttConfig.CHANNEL_NAME_OUT)public interface IMqttSender { /* * 发送信息到MQTT服务器 * * @param data 发送的文本 / void sendToMqtt(String data); /* * 发送信息到MQTT服务器 * * @param topic 主题 * @param payload 消息主体 / void sendToMqtt(@Header(MqttHeaders.TOPIC) String topic, String payload); /* * 发送信息到MQTT服务器 * * @param topic 主题 * @param qos 对消息处理的几种机制。<br> 0 表示的是订阅者没收到消息不会再次发送，消息会丢失。<br> * 1 表示的是会尝试重试，一直到接收到消息，但这种情况可能导致订阅者收到多次重复消息。<br> * 2 多了一次去重的动作，确保订阅者收到的消息有一次。 * @param payload 消息主体 / void sendToMqtt(@Header(MqttHeaders.TOPIC) String topic, @Header(MqttHeaders.QOS) int qos, String payload);}发送消息/* * MQTT消息发送 * * @author BBF /@Controller@RequestMapping(value = “/")public class MqttController { /* * 注入发送MQTT的Bean / @Resource private IMqttSender iMqttSender; /* * 发送MQTT消息 * @param message 消息内容 * @return 返回 / @ResponseBody @GetMapping(value = “/mqtt”, produces =“text/html”) public ResponseEntity<String> sendMqtt(@RequestParam(value = “msg”) String message) { iMqttSender.sendToMqtt(message); return new ResponseEntity<>(“OK”, HttpStatus.OK); }}入口类import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;import org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration;import org.springframework.context.annotation.PropertySource;/* * SpringBoot 入口类 * * @author BBF */@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})@PropertySource(encoding = “UTF-8”, value = {“classpath:config/mqtt.properties”})public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); }} ...

一个基于 swoole 的异步 mqtt 客户端库，可用于接收或者发送 mqtt 协议的消息。支持 QoS 0、QoS 1、QoS 2。支持 MQTT 3.1 和 3.1.1 版本.安装composer require try-to/swoole_mqttExamplesubscribe.php<?phpuse TrytoMqtt\Client;require_once DIR . ‘/vendor/autoload.php’;$options = [ ‘clean_session’ => false, ‘client_id’ => ‘demo-subscribe-123456’, ‘username’ => ‘’, ‘password’ => ‘’,];$mqtt = new Client(‘127.0.0.1’, 1883, $options);$mqtt->onConnect = function ($mqtt) { $mqtt->subscribe(’/World’);};$mqtt->onMessage = function ($topic, $content) { var_dump($topic, $content);};$mqtt->onError = function ($exception) use ($mqtt) { echo “error\n”; // $mqtt->reconnect(1000);};$mqtt->onClose = function () { echo “close\n”;};$mqtt->connect();命令行运行 php subscribe.php 启动publish.php<?phpuse TrytoMqtt\Client;require_once DIR . ‘/../vendor/autoload.php’;$options = [ ‘clean_session’ => false, ‘client_id’ => ‘demo-publish-123456’, ‘username’ => ‘’, ‘password’ => ‘’,];$mqtt = new Client(‘127.0.0.1’, 1883, $options);$mqtt->onConnect = function ($mqtt) { $mqtt->publish(’/World’, ‘hello swoole mqtt’);};$mqtt->onError = function ($exception) { echo “error\n”;};$mqtt->onClose = function () { echo “close\n”;};$mqtt->connect();命令行运行 php publish.php 启动实现的接口Client::__construct()Client::connect()Client::reconnect()Client::publish()Client::subscribe()Client::unsubscribe()Client::disconnect()Client::close()callback onConnectcallback onMessagecallback onErrorcallback onClose地址github地址码云地址 ...

WebSockets简介在2008年中期，开发人员Michael Carter和Ian Hickson特别敏锐地感受到Comet在实施任何真正强大的东西时所带来的痛苦和局限。 通过在IRC和W3C邮件列表上的合作，他们制定了一项计划，在网络上引入现代实时双向通信的新标准，因此创造了“WebSocket”这个名称。这个想法进入了W3C HTML草案标准，不久之后，Michael Carter写了一篇文章，将Comet社区介绍给WebSockets。 2010年，谷歌Chrome 4是第一个提供对WebSockets全面支持的浏览器，其他浏览器供应商也在接下来的几年中采用了这种方式。 2011年，RFC 6455 - WebSocket协议 - 发布到IETF网站。今天，所有主流浏览器都完全支持WebSockets，甚至包括Internet Explorer 10和11.此外，自2013年以来，iOS和Android上的浏览器都支持WebSockets，这意味着总而言之，WebSocket支持的现代环境非常健康。 大多数“物联网”或IoT也在某些版本的Android上运行，因此从2018年开始，其他类型设备上的WebSocket支持也相当普遍。那么究竟什么是WebSockets呢？简而言之，WebSockets是一个构建在设备TCP / IP堆栈之上的传输层。 目的是为Web应用程序开发人员提供本质上尽可能接近原始的TCP通信层，同时添加一些抽象来消除某些差异。 它们还满足了这样一个事实，即网络具有额外的安全考虑因素，必须将其考虑在内以保护消费者和服务提供者。您可能听说WebSockets同时被称为“传输”和“协议”。前者更准确，因为虽然它们是一种协议，因为必须遵守一套严格的规则来建立通信并包含所传输的数据，但该标准并没有对如何构建实际数据有效载荷采取任何规定。事实上，规范的一部分包括客户端和服务器就一个协议达成一致的规范，传输的数据将通过该协议进行格式化和解释。该标准将这些称为“子协议”，以避免术语中含糊不清的问题。子协议的示例是JSON，XML，MQTT，WAMP等。这些不仅可以确保数据的结构方式，还可以确保通信必须开始，继续并最终终止的方式。只要双方都了解协议所包含的内容，任何事情都会发生。 WebSocket仅提供传输层，通过该传输层可以实现该消息传递过程，这就是为什么大多数常见的子协议不是基于WebSocket的通信所独有的。关于身份验证和授权的快速说明把WebSockets看作是一个建立在TCP / IP之上的薄层，超出基本握手和消息框架规范的任何东西都需要在每个应用程序或每个库的基础上处理。 引用RFC：此协议未规定服务器在WebSocket握手期间可以对客户端进行身份验证的任何特定方式。 WebSocket服务器可以使用通用HTTP服务器可用的任何客户端身份验证机制，例如cookie，HTTP身份验证或TLS身份验证。简而言之，您仍然可以使用的基于HTTP的身份验证方法，或使用MQTT或WAMP等子协议，这两种子协议都提供身份验证和授权方法。用HTTP做连接定义WebSocket标准时的一个早期考虑因素是确保它“与网络”很好地协同工作。 这意味着认识到Web通常使用URL而不是IP地址和端口号进行寻址，并且WebSocket连接应该能够使用Web请求相同的基于HTTP的任何其他类型进行初始握手。这是一个简单的HTTP GET请求中发生的事情。假设在http://www.example.com/index….。 如果不深入到HTTP协议本身，就足以知道请求必须从所谓的Request-Line开始，然后是一系列键值对标题行，每一行都告诉服务器一些关于什么的信息。 期望在随后的请求有效负载中跟随头数据，以及它可以从客户端得到的关于它能够理解的响应类型的内容。请求中的第一个令牌是HTTP方法，它告诉服务器客户端针对引用的URL尝试的操作类型。 当客户端仅请求服务器向其提供由指定URL引用的资源的副本时，使用GET方法。根据HTTP RFC格式化的请求标头的系统示例如下所示：GET /index.html HTTP/1.1Host: www.example.com收到请求标头后，服务器然后格式化一个以状态行开头的响应标头，然后是一组键值标头对，为客户端提供来自服务器的补充信息，关于服务器的请求。 响应。 “状态行”告诉客户端HTTP状态代码（如果没有问题，通常为200），并提供解释状态代码的简短“原因”文本描述。 接下来出现键值标题对，然后是请求的实际数据（除非状态代码表明由于某种原因无法满足请求）。HTTP/1.1 200 OKDate: Wed, 1 Aug 2018 16:03:29 GMTContent-Length: 291Content-Type: text/html(additional headers…) (response payload continues here…)那么你可能会问，这与WebSockets有什么关系呢？抛弃HTTP以获得更合适的东西在发出HTTP请求并接收响应时，涉及的实际双向网络通信通过活动的TCP / IP套接字进行。浏览器中请求的Web URL通过全局DNS系统映射到IP地址，HTTP请求的默认端口为80.这意味着虽然Web URL已输入浏览器，但实际通信是通过TCP进行的/ IP，使用类似于123.11.85.9:80的IP地址和端口组合。我们现在知道，WebSockets也建立在TCP堆栈之上，这意味着我们所需要的只是客户端和服务器共同同意保持套接字连接打开并重新利用它以进行持续通信的方式。如果他们这样做，就可以发送和接收的二进制数据。要开始重新调整TCP套接字以进行WebSocket通信，客户端可以包含专门为此类用例发明的标准请求标头：GET /index.html HTTP/1.1Host: www.example.comConnection: UpgradeUpgrade: websocketConnection标头告诉服务器客户端希望协商套接字使用方式的更改。 随附的值Upgrade表示当前通过TCP使用的传输协议应该更改。 现在服务器知道客户端想要通过活动TCP套接字升级当前正在使用的协议，服务器知道要查找相应的升级头，这将告诉它客户端想要使用哪个传输协议的剩余生命周期 连接。 一旦服务器将websocket视为Upgrade标头的值，它就知道WebSocket握手过程已经开始。请注意，如果您想了解本文中介绍的更多详细信息，请参阅RFC 6455中概述了握手过程（以及其他所有内容）。避免有趣的麻烦除了上面描述的内容之外，WebSocket握手的第一部分涉及证明这实际上是一个正确的WebSocket升级握手，并且该过程不是通过客户端或可能通过某种中间欺骗来规避或模拟的。 位于中间的代理服务器。启动升级到WebSocket连接时，客户端必须包含Sec-WebSocket-Key标头，该标头具有该客户端唯一的值。 这是一个例子：Sec-WebSocket-Key: BOq0IliaPZlnbMHEBYtdjmKIL38=如果使用现代浏览器中提供的WebSocket类，上面的内容将自动处理。 您只需在服务器端查找它并生成响应。响应时，服务器必须将特殊GUID值258EAFA5-E914-47DA-95CA-C5AB0DC85B11附加到密钥，生成结果字符串的SHA-1哈希值，然后将其包含为Sec的base-64编码值。 它包含在响应中的WebSocket-Accept标头：Sec-WebSocket-Accept: 5fXT1W3UfPusBQv/h6c4hnwTJzk=在Node.js WebSocket服务器中，我们可以编写一个函数来生成这个值，如下所示：const crypto = require(‘crypto’); function generateAcceptValue (acceptKey) { return crypto .createHash(‘sha1’) .update(acceptKey + ‘258EAFA5-E914-47DA-95CA-C5AB0DC85B11’, ‘binary’) .digest(‘base64’);}然后我们只需要调用这个函数，传递Sec-WebSocket-Key头的值作为参数，并在发送响应时将函数返回值设置为Sec-WebSocket-Accept头的值。要完成握手，请将适当的HTTP响应头写入客户端套接字。 一个简单的响应看起来像这样：HTTP/1.1 101 Web Socket Protocol HandshakeUpgrade: WebSocketConnection: UpgradeSec-WebSocket-Accept: m9raz0Lr21hfqAitCxWigVwhppA=到目前为止，我们还没有完成握手 - 还有很多事情要考虑。子协议 - 统一语言客户端和服务器通常需要在给定消息内以及从一个消息到下一个消息的一段时间内，就它们如何格式化，解释和组织数据本身的兼容策略达成一致。 这就是子协议（前面提到过）的用武之地。如果客户端知道它可以处理一个或多个特定的应用程序级协议（例如WAMP，MQTT等），它可以包含它理解的协议列表。 发出初始HTTP请求。 如果它这样做，则服务器需要选择其中一个协议并将其包含在响应头中，否则将使握手失败并终止连接。子协议请求标头示例：Sec-WebSocket-Protocol: mqtt, wamp服务器在响应中发出的示例倒数标题：Sec-WebSocket-Protocol: wamp请注意，服务器必须从客户端提供的列表中精确选择一种协议。选择多个将意味着服务器无法可靠或一致地解释后续WebSocket消息中的数据。例如，如果服务器选择了json-ld和json-schema。两者都是基于JSON标准构建的数据格式，并且会有许多边缘情况，其中一个可能被解释为另一个，从而在处理数据时导致意外错误。虽然不可否认本身不是消息传递协议，但该示例仍然适用。当客户端和服务器都实现为从一开始就使用通用消息传递协议时，可以在初始请求中省略Sec-WebSocket-Protocol标头，在这种情况下服务器可以忽略此步骤。在实现通用服务，基础结构和工具时，子协议协商是最有用的，在这些服务，基础结构和工具中，一旦建立了WebSocket连接，就无法保证客户端和服务器都能相互理解。通用协议的标准化名称应在IANA注册中心注册，用于WebSocket子协议名称，在本文撰写时，已经注册了36个名称，包括soap，xmpp，wamp，mqtt等。尽管注册表是将子协议名称映射到其解释的规范来源，但唯一严格的要求是客户端和服务器就其相互选择的子协议实际意味着什么达成一致，无论它是否出现在IANA注册表中。请注意，如果客户端请求使用子协议但未提供服务器可以支持的任何内容，则服务器必须发送失败响应并关闭连接。WebSocket扩展还有一个标题用于定义数据有效负载编码和成帧方式的扩展，但在本文时，只存在一种标准化扩展类型，它提供了一种WebSocket - 等同于消息中的gzip压缩。 扩展可能发挥作用的另一个例子是多路复用 - 使用单个套接字来交错多个并发通信流。WebSocket扩展是一个有点高级的主题，并且超出了本文的范围。 现在，它足以知道它们是什么，以及它们如何适应图片。客户端 - 在浏览器中使用WebSocketsWebSocket API在WHATWG HTML Living Standard中定义，实际上非常简单易用。 构造WebSocket需要一行代码：const ws = new WebSocket(‘ws://example.org’);注意使用ws，你通常有http方案。 您也可以选择使用wss，通常使用https。 这些协议与WebSocket规范一起引入，旨在表示HTTP连接，其中包括升级连接以使用WebSockets的请求。创建WebSocket对象本身并没有做很多事情。 连接是异步建立的，因此您需要在发送任何消息之前侦听握手的完成，并且还包括从服务器接收的消息的侦听器：ws.addEventListener(‘open’, () => { // Send a message to the WebSocket server ws.send(‘Hello!’);}); ws.addEventListener(‘message’, event => { // The event object is a typical DOM event object, and the message data sent // by the server is stored in the data property console.log(‘Received:’, event.data);});还有错误和关闭事件。 连接终止时WebSockets不会自动恢复 - 这是您需要自己实现的，并且是存在许多客户端库的原因之一。 虽然WebSocket类简单易用，但它实际上只是一个基本的构建块。 必须单独实现对不同子协议或消息传递通道等附加功能的支持。生成和解析WebSocket消息帧一旦将握手响应发送到客户端，客户端和服务器就可以使用他们选择的子协议（如果有的话）开始通信。 WebSocket消息在名为“frames”的包中传递，这些包以消息头开头，并以“payload”结尾 - 此帧的消息数据。 大型消息可能会将数据分成几帧，在这种情况下，您需要跟踪到目前为止收到的内容，并在数据全部到达后将数据分组。翻译的很乱，但愿对你有点帮助 ...