MQTT学习从零到实战：二

本次基于MQTT实现的服务器之一：EMQX

协议版本：5.0

文档路径：快速开始 | EMQX 5.0 文档

MQTT协议服务器搭建

本次使用的服务器是EMQX。

下载地址：立即开始 | EMQX

从中我们也可以看出，企业版支持数据持久化，需要收费。如果是对数据没有太高要求的话，可以使用免费版。开源版个人认为适用场景：实现手机远程控制家中的灯光、门窗、温度等设备。设备的心跳检测等对数据要求稍低的场景。例如心跳少跳一次或者温度少发送几次，不会影响整体业务的需求。

我们以Windows版本为例：

访问：http://localhost:18083/ 默认账号：admin 默认密码：public

备注：EMQX支持集群，访问控制等等。。具体可以参考文档！此次只介绍一些基础的信息。

MQTT协议属于C/S服务，因此，我们要再启动客户端。

按文档操作客户端：安装 - MQTTX 文档

客户端安装访问后：

这个时候客户端和服务器我们都有了，可以自己参考文档进行相关的配置。

介绍一些名词或功能：

服务端

在发布消息的客户端和订阅的客户端之间充当中介，将所有接收到的消息转发到匹配的订阅客户端。所以有时我们也会直接将服务端称为 Broker。

客户端

使用 MQTT 协议连接到 MQTT 服务端的设备或应用程序。它既可以是发布者，也可以是订阅者，也可以具备这两种身份。

主题

主题被用来标识和区分不同的消息，它是 MQTT 消息路由的基础。发布者可以在发布时指定消息的主题，订阅者则可以选择订阅自己感兴趣的主题来接收相关的消息。

通配符

订阅者可以在订阅的主题中使用通配符来达到一次订阅多个主题的目的。MQTT 提供了单层通配符和多层通配符两种主题通配符，以满足不同的订阅需要。

QoS

MQTT 定义了三种 QoS 等级，来分别提供不同的消息可靠性保证。每条消息都可以在发布时独立设置自己的 QoS。QoS 0 最多交付一次，消息可能丢失；QoS 1 至少交付一次，消息可以保证到达，但是可能重复；QoS 2 只交付一次，消息保证到达，并且不会重复。QoS 越大，消息的传输复杂程度也越高，我们需要根据实际场景来选择合适的 QoS。

会话

QoS 只是设计了消息可靠到达的理论机制，而会话则确保了 QoS 1、2 的协议流程得以真正实现。

会话是客户端与服务端之间的有状态交互，它可以仅持续和网络连接一样长的时间，也可以跨越多个网络连接存在，我们通常将后者称为持久会话。我们可以选择让连接从已存在的会话中恢复，也可以选择从一个全新的会话开始。

保留消息

与普通消息不同，保留消息可以保留在 MQTT 服务器中。任何新的订阅者订阅与该保留消息中的主题匹配的主题时，都会立即接收到该消息，即使这个消息是在它们订阅主题之前发布的。

这使订阅者在上线后可以立即获得数据更新，而不必等待发布者再次发布消息。在某种程度上，我们可以把保留消息当作是一个消息 “云盘” 来使用：随时上传消息到 “云盘”，然后在任意时刻从 “云盘” 获取消息。当然，这个 “云盘” 还有一个主题下只能存储一条最新的保留消息的限制。

遗嘱消息

发布订阅模式的特性决定了，除了服务器以外没有客户端能够感知到某个客户端从通信网络中离开。而遗嘱消息则为连接意外断开的客户端提供了向其他客户端发出通知的能力。

客户端可以在连接时向服务器设置自己的遗嘱消息，服务器将在客户端异常断开后立即或延迟一段时间后发布这个遗嘱消息。而订阅了对应遗嘱主题的客户端，将收到这个遗嘱消息，并且采取相应的措施，例如更新该客户端的在线状态等等。

共享订阅

默认情况下，消息会被转发给所有匹配的订阅者。但有时，我们可能希望多个客户端协同处理接收到的消息，以便以水平扩展的方式来提高负载能力。又或者，我们希望为客户端增加一个备份客户端，当主客户端离线时，能够无缝切换到备份客户端继续接收消息，以确保高可用性。。

而 MQTT 的共享订阅特性，则提供了这一能力。我们可以将客户端划分为多个订阅组，消息仍然会被转发给所有订阅组，但每个订阅组内每次只会有一个客户端收到消息。

$SYS 主题

以 $SYS/ 为前缀的主题被保留给服务器用来发布一些特定的消息，比如服务器的运行时间、客户端的上下线事件通知、当前连接的客户端数量等等。我们一般将这些主题称为系统主题，客户端可以订阅这些系统主题来获取服务器的有关信息。

延迟发布

延迟发布可以实现按照用户配置的时间间隔延迟发布消息，当客户端使用特殊主题前缀 $delayed/{DelayInteval} 发布消息时，将触发延迟发布功能。

延迟发布主题的具体格式如下：

$delayed/{DelayInterval}/{TopicName}

$delayed：使用 $delay 作为主题前缀的消息都将被视为需要延迟发布的消息。延迟间隔由下一主题层级中的内容决定。
{DelayInterval}：指定该 MQTT 消息延迟发布的时间间隔，单位是秒，允许的最大间隔是 4294967 秒。如果 {DelayInterval} 无法被解析为一个整型数字，EMQX 将丢弃该消息，客户端不会收到任何信息。
{TopicName}：MQTT 消息的主题名称。

例如:

$delayed/15/x/y：15 秒后将 MQTT 消息发布到主题 x/y。
$delayed/60/a/b：1 分钟后将 MQTT 消息发布到 a/b。
$delayed/3600/$SYS/topic：1 小时后将 MQTT 消息发布到 $SYS/topic。

配置延迟发布

delayed {
    enable = true
    max_delayed_messages = 12435
}

enable：表示开启或关闭延迟发布功能。

max_delayed_messages：表示允许同时存在的延迟发布的消息的最大数量。

自动订阅

自动订阅能够给 EMQX 设置多个规则，在设备成功连接后按照规则为其订阅指定主题，不需要额外发起订阅。

排它订阅

排它订阅允许对主题进行互斥订阅，一个主题同一时刻仅被允许存在一个订阅者，在当前订阅者未取消订阅前，其他订阅者都将无法订阅对应主题。

排它订阅的前缀和示例：

示例	前缀	真实主题名
$exclusive/t/1	$exclusive/	t/1

当某个客户端 A 订阅 $exclusive/t/1 后，其他客户端再订阅 $exclusive/t/1 时都会失败，直到 A 取消了对 $exclusive/t/1 的订阅为止。

注意: 排它订阅必须使用 $exclusive/ 前缀，在上面的示例中，其他客户端依然可以通过 t/1 成功进行订阅。

下面提前一些笔者感兴趣的功能，如果想了解其它功能，可以参考文档。

1.在搭配数据桥接的前提下，支持sql数据的处理。向我们展示了字段，内置的SQL函数等等。

2.通过数据桥接，用户可以实时地将消息从 EMQX 发送到外部数据系统。如果使用双向数据桥接，用户还可以从外部数据系统拉取数据并发送到 EMQX 的某个主题。支持常用的Kafka/redis/mysql/mongodb等等。（企业版才支持，收费的）也支持MQTT服务器之间的桥接转发等等。

3.支持SSL/TLS连接

4.支持备份与恢复

EMQX 5.1 引入了一个用户友好的命令行工具用于数据导入和导出。尽管与 EMQX 4.x 中提供的工具类似，但它具有一些显著的差异，并且与之不兼容。

在 EMQX 4.x 中，使用单个 JSON 文件保存 EMQX 配置和内置数据库的所有必要数据。然而，在 EMQX 5.1 中，将导出的数据压缩为 tar 格式的文件，这样可以更高效、更有结构地处理潜在的大量用户数据。

5.速率限制

EMQX 提供对接入速度、消息速度的限制，从入口处避免了系统过载，保证了系统的稳定和可预测的吞吐。配置文件：emqx.conf

6.告警

EMQX 内置监控与告警功能，目前支持监控 CPU 占用率、系统与进程的内存占用率、进程数量、规则引擎资源状态、集群脑裂与愈合，并会在发现异常时进行告警。告警的激活与取消都将产生一条警告日志，EMQX 会同时发布一条主题为 $SYS/brokers/<Node>/alarms/activate 或 $SYS/brokers/<Node>/alarms/deactivate 的 MQTT 消息，用户可以通过订阅对应主题来获取告警通知。

7.日志

通过 EMQX 的日志功能，您可查看客户端访问、操作系统或网络异常等问题，如登录错误，异常访问，性能故障等等，并基于日志信息进行问题排查或系统性能优化。

EMQX 支持两种不同的日志输出方式：控制台输出日志和文件输出日志。您可以根据需要选择输出方式或同时启用这两种方式。

为避免日志数据过多或日志写入过慢等问题，EMQX 默认开启了过载保护机制，以确保正常业务不被日志影响。

8.主题监控

EMQX 提供了主题监控功能，可以统计指定主题下的消息收发数量、速率等指标。您可以通过 Dashboard 的 问题分析 -> 主题监控 页面查看和使用这一功能，也可以通过 HTTP API 完成相应操作。

9.集成 Prometheus

可选择提供结合 Prometheus 和 Grafana 实现 EMQX 统计指标可视化。

关于EMQX服务器具体使用，感兴趣的朋友自己去看一下对应的产品文档。以上只是粗略介绍！