EMQX从搭建到作用于MQTT

EMQX与MQTT的关系

EMQX（Erlang MQTT Broker）是一个开源的高性能、分布式 MQTT 消息代理服务器，专门用于实现 MQTT 协议的消息传递。MQTT（Message Queuing Telemetry Transport）则是一种轻量级的、发布/订阅模式的消息传输协议，通常用于物联网（IoT）设备之间的通信。

二者关系如下：

​ 1. 协议与实现：MQTT 是一种协议，定义了消息发布、订阅、分发的标准；而 EMQX 是基于此协议实现的消息代理服务。EMQX 支持 MQTT 3.1、3.1.1 和 5.0 版本的协议。

​ 2. 应用场景：EMQX 被用作 MQTT 协议的消息代理，广泛应用于需要大量设备接入、消息传输高并发的物联网场景，如智慧城市、智能家居和工业自动化等。

​ 3. 分布式和高可用性：相比于一些单节点 MQTT 代理，EMQX 支持分布式架构，具备高可用性和高扩展性，适合大规模 IoT 场景。

简而言之，EMQX 是一个符合 MQTT 标准协议的服务器实现，用于物联网环境中需要高并发和大规模消息传输的应用。

EMQX搭建

官网下载各种版本-平台

docker搭建

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083   -v /acowbo/emqx/data:/opt/emqx/data   -v /acowbo/emqx/log:/opt/emqx/log --user root  emqx/emqx:5.8.1

这里不指定–user，会报权限问题，但是指定了又相对不安全，如果是生产环境建议赋权或者另辟蹊径

端口说明

EMQX 服务器通常使用以下 4 个主要端口，每个端口负责不同的功能模块

1883 端口

• 作用：这是 MQTT 协议的标准端口，负责接收客户端基于 MQTT 的连接请求。
• 特点：不支持加密，适合内网或者无需加密的连接方式。客户端连接时不需要 SSL 或 TLS 配置。
• 典型应用：主要用于 IoT 设备、应用程序、传感器等连接到 MQTT 服务器，并进行数据发布或订阅。

8883 端口

• 作用：这是 MQTT 协议的加密端口，和 1883 端口的功能一致，但支持 SSL/TLS 加密。
• 特点：适合在公网或需要加密通信的场景下使用。确保了传输过程中消息的保密性和完整性。
• 典型应用：当设备或客户端在公网中传输敏感数据时，使用 8883 端口能提供更好的安全性。

8083 端口

• 作用：这是基于 WebSocket 的 MQTT 连接端口，允许 Web 应用（如浏览器客户端）通过 WebSocket 协议连接到 MQTT 服务器。
• 特点：适用于浏览器等支持 WebSocket 的应用程序。使用非加密连接，不需要 SSL/TLS。
• 典型应用：通过网页或者 Web App 客户端与 EMQX 进行通信，适合物联网管理平台等前端可视化系统连接到 EMQX。

8084 端口

• 作用：这是 WebSocket 连接的加密端口，提供基于 WebSocket 的 MQTT 连接，并支持 SSL/TLS 加密。
• 特点：与 8083 类似，但支持加密，适合对外提供服务的应用场景，能保证传输数据的安全性。
• 典型应用：需要 WebSocket 加密的场景，例如 Web 应用在公网访问 EMQX 时，用于与物联网设备安全通信。

18083端口

• **作用：**web访问，在浏览器中输入 http://<your-ip>:18083 即可访问 EMQX 的 Dashboard 页面
• 功能：
  • 连接管理：查看当前连接的客户端信息，包括连接数、连接状态等。
  • 主题监控：查看和管理订阅的主题，监控消息发布和接收情况。
  • 规则引擎：配置数据处理规则，实现消息过滤、转发等操作。
  • 统计信息：查看系统的性能指标，例如吞吐量、内存使用情况等
  • 配置和管理：可以配置认证、权限控制、插件等，方便维护和管理集群。
  • 默认登录信息admin:public

为了系统安全，建议首次登录后尽快修改默认密码。

成功示意图

忘记密码

如果忘记密码需要进入容器进行修改，执行命令如下

./bin/emqx_ctl admin password admin 密码

MQTTX模拟实现生产消费

官网下载各种版本

MQTTX 是一款开源的 MQTT 客户端应用程序，用于调试和测试 MQTT 连接。它支持常用的 MQTT 功能，可以帮助开发者在开发物联网（IoT）和消息传递系统时便捷地测试 MQTT 消息传输和主题订阅。主要特点包括：

1. 多平台支持：MQTTX 支持 Windows、macOS 和 Linux 系统，方便跨平台使用。
2. 图形界面：与基于命令行的 MQTT 客户端不同，MQTTX 提供了直观的 GUI，可以轻松配置和管理多个 MQTT 连接。
3. 主题订阅与发布：可以快速创建和测试主题的订阅和消息的发布，以查看消息是否能够正常发送和接收。
4. 支持多种 MQTT 版本：MQTTX 支持常见的 MQTT 协议版本（如 3.1、3.1.1 和 5.0），并提供客户端 ID、保持连接（Keep Alive）、QoS、遗嘱消息等常用配置项。

通过 MQTTX，用户可以轻松测试 MQTT 服务器的连接性和功能，非常适合调试 MQTT 应用的消息传递。

使用MQTTX创建生产者，消费者，主题

可以在刚刚搭建的EMQX中看到这两个

借用第一张图说明一下关于订阅主题的说明

在 MQTT 协议中，消费者（也称“订阅者”）需要订阅主题以接收消息，而生产者（也称“发布者”）不需要订阅主题。生产者直接向主题发送消息，消费者则订阅该主题并等待接收消息。以下是两者的角色细分：

1. 生产者（发布者）：

   • 负责向某个主题发布消息，例如 testtopic/acowbo。
   • 只需指定要发布的主题和内容，而不需要订阅主题。

2. 消费者（订阅者）：

   • 订阅生产者发布的主题，例如 testtopic/#。
   • 通过订阅主题，消费者会接收该主题下所有匹配的消息。

主题通配符详解

在 MQTT 中，testtopic/# 是一个通配符主题，用于匹配以 testtopic 开头的所有主题。例如：

​ • testtopic/temperature

​ • testtopic/humidity

​ • testtopic/sensor/1

​ • testtopic/sensor/2/data

通配符 # 是多层次通配符，可以匹配它前面的主题层级及之后的所有子层级主题，因此订阅 testtopic/# 意味着将收到 testtopic 下所有子主题发布的消息。

通配符规则

在 MQTT 中，通配符订阅有两种形式：

​ 1. #：多层次匹配，适用于所有层级。例如，a/# 可以匹配 a/b、a/b/c 等。

​ 2. +：单层次匹配，仅匹配某一层。例如，a/+ 可以匹配 a/b，但不匹配 a/b/c。

testtopic/# 的使用适合场景是，应用中需要监听整个testtopic主题下所有的子主题数据。

QOS详解

MQTT（消息队列遥测传输）是一种轻量级的消息传输协议，常用于物联网（IoT）应用。MQTT提供了不同的服务质量（Quality of Service，简称QoS）级别，以满足不同场合下对消息传递可靠性的需求。QoS级别分为三个主要类型：

1. QoS 0 - 至多一次（At most once）

• 特性：消息发送后不进行确认，消息可能丢失或重复，但不会重复发送。
• 适用场景：用于对消息可靠性要求不高的场景，如传感器数据的定期上报，丢失少量数据不会影响整体系统的功能。
• 优点：响应速度快，资源消耗低。
• 缺点：可能会丢失消息，不保证到达。

2. QoS 1 - 至少一次（At least once）

• 特性：发送方会等待接收方的确认，如果未收到确认，发送方会重新发送该消息。这意味着消息至少会被送达一次，但可能会出现重复消息。
• 适用场景：在对消息丢失有一定容忍度的情况下，使用此级别是比较合适的，如重要数据的传输，但不希望丢失。
• 优点：保证消息至少到达一次，降低了丢失的可能性。
• 缺点：可能导致消息重复，需要在接收方进行去重操作。

3. QoS 2 - 只有一次（Exactly once）

• 特性：这是最高的QoS级别，确保每条消息只会被传递一次，使用四步握手协议来保证消息的唯一性。
• 适用场景：适用于对数据准确性要求极高的场景，如金融交易等，这类应用需要确保每一条消息都不会被丢失或重复。
• 优点：消除了重复消息的可能性，确保了消息的唯一性和准确性。
• 缺点：实现复杂，性能开销较大，导致延迟增加。

总结

选择适当的QoS级别取决于具体的应用需求和网络环境。一般来说：

• 如果对消息丢失不敏感，选择QoS 0。
• 如果需要确保消息到达但可以容忍重复，选择QoS 1。
• 如果对消息的准确性和唯一性有严格要求，选择QoS 2。

在设计MQTT应用时，应综合考虑应用场景、网络状况和资源消耗，以选择合适的QoS设置。