EMQX从搭建到作用于MQTT
🎏：你只管努力，剩下的交给时间
🏠 ：小破站
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://:18083 即可访问 EMQX 的 Dashboard 页面
- 功能：
- 连接管理：查看当前连接的客户端信息，包括连接数、连接状态等。
- 主题监控：查看和管理订阅的主题，监控消息发布和接收情况。
- 规则引擎：配置数据处理规则，实现消息过滤、转发等操作。
- 统计信息：查看系统的性能指标，例如吞吐量、内存使用情况等
- 配置和管理：可以配置认证、权限控制、插件等，方便维护和管理集群。
- 默认登录信息admin:public
为了系统安全，建议首次登录后尽快修改默认密码。
成功示意图
忘记密码
如果忘记密码需要进入容器进行修改，执行命令如下
./bin/emqx_ctl admin password admin 密码
MQTTX模拟实现生产消费
MQTTX 是一款开源的 MQTT 客户端应用程序，用于调试和测试 MQTT 连接。它支持常用的 MQTT 功能，可以帮助开发者在开发物联网（IoT）和消息传递系统时便捷地测试 MQTT 消息传输和主题订阅。主要特点包括：
- 多平台支持：MQTTX 支持 Windows、macOS 和 Linux 系统，方便跨平台使用。
- 图形界面：与基于命令行的 MQTT 客户端不同，MQTTX 提供了直观的 GUI，可以轻松配置和管理多个 MQTT 连接。
- 主题订阅与发布：可以快速创建和测试主题的订阅和消息的发布，以查看消息是否能够正常发送和接收。
- 支持多种 MQTT 版本：MQTTX 支持常见的 MQTT 协议版本（如 3.1、3.1.1 和 5.0），并提供客户端 ID、保持连接（Keep Alive）、QoS、遗嘱消息等常用配置项。
通过 MQTTX，用户可以轻松测试 MQTT 服务器的连接性和功能，非常适合调试 MQTT 应用的消息传递。
使用MQTTX创建生产者，消费者，主题
可以在刚刚搭建的EMQX中看到这两个
借用第一张图说明一下关于订阅主题的说明
在 MQTT 协议中，消费者（也称“订阅者”）需要订阅主题以接收消息，而生产者（也称“发布者”）不需要订阅主题。生产者直接向主题发送消息，消费者则订阅该主题并等待接收消息。以下是两者的角色细分：
-
生产者（发布者）：
- 负责向某个主题发布消息，例如 testtopic/acowbo。
- 只需指定要发布的主题和内容，而不需要订阅主题。
-
消费者（订阅者）：
- 订阅生产者发布的主题，例如 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设置。
原文地址：https://blog.csdn.net/Mrxiao_bo/article/details/143853123
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！