EMQ X

### Inflight Window 与 Message Queue 说明 为了提高消息吞吐效率和减少网络波动带来的影响，EMQ X 消息服务器允许多个未确认的 QoS 1 和 QoS 2 报文同时存在于网路链路上。这些已发送但未确认的报文将被存放在 inflight Window 中直至完成确认。 当网络链路中同时存在的报文超出限制，即 Inflight Window 到达长度限制（见 `max_inflight`）时，EMQ X 消息服务器将不再发送后续的报文，而是将这些报文存储在 Message Queue 中。一旦 Inflight Window 中有报文完成确认，Message Queue 中的报文就会以先入先出的顺序被发送，同时存储到 Inflight Window 中。 当客户端离线时，Message Queue 还会被用来存储 QoS 0 消息，这些消息将在客户端下次上线时被发送。这功能默认开启，当然你也可以手动关闭，见 `mqueue_store_qos0`。 需要注意的是，如果 Message Queue 也到达了长度限制，后续的报文将依然缓存到 Message Queue，但相应的 Message Queue 中最先缓存的消息将被丢弃。如果队列中存在 QoS 0 消息，那么将优先丢弃 QoS 0 消息。因此，根据你的实际情况配置一个合适的 Message

MQTT X 是由全球领先的开源物联网中间件提供商 EMQ 开源的一款跨平台 MQTT 5.0 桌面客户端，它支持 macOS，Linux，Windows。 MQTT X 的用户界面借助聊天软件的形式简化了页面的操作逻辑，用户可以快速创建连接保存并同时建立多个连接客户端，方便用户快速测试 MQTT/TCP、MQTT/TLS 的连接、发布/订阅功能及其他特性。 项目地址： GitHub 官方网站： MQTT X Website MQTT X 适用于正在搭建自己的 MQTT 的消息服务器的用户来测试连接，订阅和发布消息等，在使用客户端时，用户既可以是发布者，也 可以是订阅者。也适用于正在开发或研究 MQTT Broker 的相关用户。在 MQTT 的研究与应用中，无论你身处什么阶段 都可以通过 MQTT X 快速、深入地理解 MQTT 协议相关特性。 该项目完全开源，项目采用了 Vue.js + TypeScript + Electron 的技术栈进行开发，你可以在 GitHub 上查看和浏览项目源码。欢迎前来一起讨论和学习 Electron 项目开发技术。 以下为 MQTT X 的特性和界面的预览： 跨平台，支持 Windows，macOS，Linux 完整支持 MQTT v3.1.1 以及 MQTT v5.0 协议 支持 CA、自签名证书，以及单、双向 SSL/TLS 认证

前言 安全保护几乎对于所有的项目都是一个挑战，对于物联网项目更是如，自普及应用以来物联网业内已经发生过多起安全事故。 作为物联网通信协议事实标准，MQTT 保持着较高的安全性，提供了多层次的安全设计： 传输层：MQTT 基于 TCP/IP 协议，可以在传输层上使用 SSL/TLS 进行加密传输： 使用 SSL/TLS 加密通信数据，防止中间人攻击； 使用客户端证书作为设备身份凭证，验证设备合法性。 应用层：使用 MQTT 自身的安全特性进行防护： MQTT 协议支持用户名和密码实现客户端的身份校验； MQTT Broker 实现了 Topic 的读写权限控制（Topic ACL）。 EMQ X 完整支持 MQTT 各项安全规范，内置的安全功能无需编程开箱即用，可以快速排除项目中的安全隐患。本系列将围绕各个层次的安全规范，介绍如何通过配置 EMQ X 启用相关功能最终实现相应的安全防护。 emqx-auth-mysql 简介 emqx_auth_mysql 是基于 MySQL 数据库的 MQTT 认证/访问控制插件，通过检查每个终端接入的 username 和 password 是否与用户指定的 MySQL 数据库中存储的信息一致性来实现对终端的连接认证和访问控制。其功能逻辑如下： 本文仅介绍认证功能，ACL 功能见后续文章。 认证原理 设备连接时 EMQ X

本文以在 CentOS 7.2 中的实际例子来说明如何通过 MySQL 来存储相关的 MQTT 数据。 MySQL 属于传统的关系型数据库产品，其开放式的架构使得用户的选择性很强，而且随着技术的逐渐成熟，MySQL 支持的功能也越来越多，性能也在不断地提高，对平台的支持也在增多，此外，社区的开发与维护人数也很多。当下，MySQL 因为其功能稳定、性能卓越，且在遵守 GPL 协议的前提下，可以免费使用与修改，因此深受用户喜爱。 安装与验证 MySQL 服务器 读者可以参考 MySQL 官方文档 或使用 Docker 来下载安装 MySQL 服务器，本文章使用 MySQL 5.6 版本。 为方便管理操作，可下载使用官方免费图形化管理软件 MySQL Workbeanch 。 如果读者使用的是 MySQL 8.0 及以上版本，MySQL 需按照 EMQ X 无法连接 MySQL 8.0 教程特殊配置。 准备 初始化数据表 插件运行依赖以下几张数据表，数据表需要用户自行创建，表结构不可改动。 mqtt_client 存储设备在线状态 DROP TABLE IF EXISTS `mqtt_client`; CREATE TABLE `mqtt_client` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `clientid` varchar

MQTT 5.0 - 发布订阅模式介绍 MQTT 协议的核心在于发布订阅模式，在本文中，我们将对这一模式进行深入的介绍。 发布订阅模式 发布订阅模式区别于传统的客户端-服务器模式，它使 发送消息的客户端（发布者）与接收消息的客户端（订阅者）分离 ，发布者与订阅者不需要建立直接联系。我们既可以让多个发布者向一个订阅者发布消息，也可以让多个订阅者同时接收一个发布者的消息，它的精髓在于由一个被称为代理的中间角色负责所有消息路由和分发的工作。传统的客户端-服务器模式可以实现类似的效果，但是无法做到像发布订阅模式这样简洁和优雅。 发布订阅模式的优点在于发布者与订阅者的解耦，这种解耦表现在以下两个方面： 空间解耦，订阅者与发布者不需要建立直接连接，新的订阅者想要加入网络时不需要修改发布者的行为。 时间解耦，订阅者和发布者不需要同时在线，即便不存在订阅者也不影响发布者发布消息。 消息路由 代理作为发布订阅模式的关键角色，它需要准确、高效地向订阅者转发其期望的消息，一般来说，比较常用的有以下两种方式： 根据主题。订阅者向代理订阅自己感兴趣的主题，发布者发布的所有消息中都会包含自己的主题，代理根据消息的主题判断需要将消息转发给哪些订阅者。 根据消息内容。订阅者定义其感兴趣的消息的条件，只有当消息的属性或内容满足订阅者定义的条件时，消息才会被投递到该订阅者。严格来讲，主题也可以算是消息内容的一种。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一，win10下安装EMQ 1，下载解压（链接 https://www.emqx.io/downloads ） 2，将压缩包放在D，F根目录下进行解压，进入bin下, 执行emqx start, emqx.status, emqx stop, emqx uninstall; 3，浏览器地址 http://127.0.0.1:18083 ， 用户名密码admin/public 来源： oschina 链接： https://my.oschina.net/u/3290532/blog/3155439

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Kuiper 团队宣布发布 Kuiper 0.1。Kuiper 0.1 可以从这里下载 。 EMQ X Kuiper 是 Golang 实现的轻量级物联网边缘分析、流式处理开源软件，可以运行在各类资源受限的边缘设备上。Kuiper 设计的一个主要目标就是将在云端运行的实时流式计算框架（比如 Apache Spark ， Apache Storm 和 Apache Flink 等）迁移到边缘端。Kuiper 参考了上述云端流式处理项目的架构与实现，结合边缘流式数据处理的特点，采用了编写基于 源 (Source) ， SQL (业务逻辑处理) , 目标 (Sink) 的规则引擎来实现边缘端的流式数据处理。 网址： https://www.emqx.io/products/kuiper Github仓库： https://github.com/emqx/kuiper 概览 功能 性能优化 提供了针对 Kuiper 规则设置并发度的配置选项，在不同的场景下可以对其优化 在 source 里的 concurrency 设置：设置运行的协程数，默认值为1。如果设置协程数大于1，必须使用共享订阅模式。 在 sink 里的 concurrency 设置：设置运行的线程数。该参数值大于1时，消息发出的顺序可能无法保证。 在

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> MQTT 协议通过交换预定义的MQTT控制报文来通信。下面以 MQTTX 为例，展示如何通过 MQTT 报文实现发布订阅功能。 Connect 连接 MQTT 协议基于 TCP/IP 协议，MQTT Broker 和 Client 都有需要有 TCP/IP 地址。 Broker 如果你暂时没有一个可用的 MQTT Broker， EMQ X 提供了一个公共 Broker 地址用于测试： broker.emqx.io:1883 。 Client MQTTX 工具中 Client 的配置其实是 MQTT 协议中 Connect 报文的配置，下面解释一下相关配置项： Client ID 服务端使用 ClientId 识别客户端。连接服务端的每个客户端都有唯一的 ClientId 。客户端和服务端都必须使用 ClientId 识别两者之间的 MQTT 会话相关的状态。 ClientId 必须存在，但是服务端可以允许客户端提供一个零字节的 ClientId，如果这样做了，服务端必须将这看作特殊情况并分配唯一的 ClientId 给那个客户端。然后正常处理这个 CONNECT 报文。 Username/Password MQTT 可以通过发送用户名和密码来进行相关的认证和授权，但是，如果此信息未加密

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着 5G 时代的来临，万物物联的伟大构想正在成为现实。联网的物联网设备在 2018 年已经达到了 70 亿[^1]，在未来两年，仅智能水电气表就将超过10亿[^2]。 海量的设备接入和设备管理对网络带宽、通信协议以及平台服务架构都带来了很大挑战。对于物联网协议来说，必须针对性地解决物联网设备通信的几个关键问题：其网络环境复杂而不可靠、其内存和闪存容量小、其处理器能力有限。 MQTT 是基于 Publish/Subscribe 模式的物联网通信协议，凭借简单易实现、支持 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)时

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 什么是主题 MQTT 协议通过网络传输应用消息。应用消息通过 MQTT 传输时，它们有关联的服务质量（QoS）和主题（Topic）。主题本质上是一个字符串，MQTT 协议规定主题是UTF-8编码的字符串，这意味着，主题过滤器和主题名的比较可以通过比较编码后的 UTF-8 字节或解码后的 Unicode 字符。 主题名和主题过滤器 主题名 附加在应用消息上的一个标签，服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户端订阅。 主题过滤器 订阅中包含的一个表达式，用于表示相关的一个或多个主题。主题过滤器可以使用通配符。 主题可能是管理员在服务端预先定义好的，也可能是服务端收到第一个订阅或使用那个主题名的应用消息时动态添加的。服务端也可以使用一个安全组件有选择地授权客户端使用某个主题资源。 如果订阅的主题过滤器与消息的主题名匹配，应用消息会被发送给每一个匹配的客户端订阅。主题资源可以是管理员在服务端预先定义好的，也可以是服务端收到第一个订阅或使用那个主题名的应用消息时动态添加的。服务端可以使用一个安全组件有选择地授权客户端使用某个主题资源。 主题和主题过滤器命名的规则 所有的主题名和主题过滤器必须至少包含一个字符。 主题名和主题过滤器是大小写敏感的。 ACCOUNTS 和 Accounts