MQTT 协议快速体验
全球物联网正在高速发展，专门针对低带宽和不稳定网络环境的物联网应用设计的 MQTT 协议也因此得到广泛应用。
MQTT 是一种基于发布/订阅模式轻量级消息传输协议，具有简单易实现、支持 QoS、报文小等特点，非常适用于工业互联网、车联网、智能硬件、电力能源等领域。
本文将通过讲解与演示向读者展示 MQTT 协议的入门使用流程，物联网及 MQTT 初学者可以通过本文以更简单的方式理解 MQTT 相关概念，快速开始 MQTT 服务及应用的开发。
MQTT 连接
在使用 MQTT 协议进行通信之前，需要先建立一个 MQTT 连接，连接由客户端向服务器端发起。
MQTT 客户端
任何运行了 MQTT 客户端库的程序或设备都是一个 MQTT 客户端，例如：使用了 MQTT 的即时通讯 APP 是一个客户端，使用 MQTT 上报数据的各种传感器设备是一个客户端，以及各种 MQTT 测试工具也是一个客户端。
目前，基本所有的编程语言都有成熟的开源 MQTT 客户端库，读者可参考 EMQ 整理的 MQTT 客户端库大全选择一个合适的客户端库来构建满足自身业务需求的 MQTT 客户端。也可直接访问 EMQ 提供的 MQTT 客户端编程系列博客，学习如何在 Java、Python、PHP、Node.js 等编程语言中使用 MQTT。
本次演示我们将使用由 MQTT X 提供的支持浏览器访问的在线 MQTT 客户端。MQTT X 是目前开源客户端中 GitHub Star 数最多的，它同时也提供了桌面客户端与命令行客户端。
MQTT 服务器
MQTT 服务器负责接收客户端发起的连接，并将客户端发送的消息转发到另外一些符合条件的客户端。一个成熟的 MQTT 服务器可支持海量的客户端连接及百万级的消息吞吐，帮助物联网业务提供商专注于业务功能并快速创建一个可靠的 MQTT 应用。
MQTT 服务器一般有私有部署、全托管云服务、公共在线三种形式。
私有部署需要自行搭建与维护服务器，适合接入量较大、且有技术团队支持的公司。
读者若是希望搭建私有 MQTT 服务器进行测试，可运行如下 Docker 命令使用 EMQX 开源版。
全托管云服务免除了企业维护基础设施的负担，简单几步就能轻松开启 MQTT 服务。如下图，EMQX Cloud 支持按连接创建 MQTT 服务，且可选择部署在多个云平台。
公共的在线服务器一般由各个 MQTT 服务器的所属商业公司所提供，主要用来做 MQTT 流程测试。
本次演示我们将使用由 EMQ 提供的公共 MQTT 服务器，该服务器基于全托管的 MQTT 云服务-EMQX Cloud 创建，服务器信息如下：
Broker： broker.emqx.io
TCP Port： 1883
Websocket Port： 8083
发布与订阅
连接成功后，客户端就能进行消息的收发，在消息收发前我们需要先理解发布/订阅模式。
发布/订阅模式
发布订阅模式区别于传统的客户端-服务器模式，它使发送消息的客户端（发布者）与接收消息的客户端（订阅者）分离，发布者与订阅者不需要建立直接联系。我们既可以让多个发布者向一个订阅者发布消息，也可以让多个订阅者同时接收一个发布者的消息，它的精髓在于由一个被称为代理（MQTT 服务器）的中间角色负责所有消息路由和分发的工作。
下图为 MQTT 的发布/订阅流程：温度传感器作为一个客户端连接至 MQTT 服务器后，即可向某个主题（比如 Temperature）发布温度消息，服务器收到该消息后会将消息转发至订阅了 Temperature 主题的客户端（比如下图的手机、浏览器等应用）。
主题（Topic）
MQTT 协议基于主题进行消息路由，主题类似 URL 路径，例如：
主题通过 / 分割层级，支持 +， # 通配符:
+：表示通配一个层级，例如 a/+ 匹配 a/x， a/y
#：表示通配多个层级，例如 a/# 匹配 a/x，a/b/c/d
消息服务质量（QoS）
MQTT 协议提供了 3 种消息服务质量等级（Quality of Service），它保证了在不同的网络环境下消息传递的可靠性。
QoS 0：消息最多传递一次。
如果当时客户端不可用，则会丢失该消息。发布者发送一条消息之后，就不再关心它有没有发送到对方，也不设置任何重发机制。
QoS 1：消息传递至少 1 次。
包含了简单的重发机制，发布者发送消息之后等待接收者的 ACK，如果没收到 ACK 则重新发送消息。这种模式能保证消息至少能到达一次，但无法保证消息重复。
QoS 2：消息仅传送一次。
设计了重发和重复消息发现机制，保证消息到达对方并且严格只到达一次。
订阅主题
接下来我们模拟温度传感器场景，在之前创建的 Simple Demo 连接里订阅所有的温度传感器上报的温度数据，即订阅通配符主题 sensor/+/temperature。
如下图，点击按钮 New Subscription，在弹出框的 Topic 下面输入主题 sensor/+/temperature，QoS 保持默认 0 不变。
Color 字段可修改订阅标签的颜色，Alias 字段可修改订阅主题的显示名称。这两个字段为该在线客户端特有，使用代码连接时无此参数。
订阅成功后即可看到中间的订阅列表里多了一条记录。
发布消息
接下来我们点击最左侧的 + 按钮分别创建 Sensor 1 和 Sensor 2 两个连接，模拟两个温度传感器。
连接创建好后如下图所示，将会看到 3 个连接，并且连接左侧的在线状态圆点都为绿色（绿色说明连接成功）。
选中 Sensor 1 连接，在页面右下部分输入发布主题 sensor/1/temperature，消息框内输入如下 JSON 格式消息，并点击右侧最底部的发布按钮发送消息。
如下表示消息发送成功。
使用同样的步骤，在 Sensor 2 连接里向 sensor/2/temperature 主题发布如下 JSON 消息。
将会看到 Simple Demo 连接收到 2 条新消息。
点击 Simple Demo 连接，将会看到两个传感器发送的两条消息。
MQTT 重要特性演示
保留消息（Retained Message）
MQTT 客户端向服务器发布消息时，可以设置保留消息标志。一个主题下最新一条保留消息会驻留在消息服务器，后来的订阅者订阅主题时仍可以接收该消息。
如下图，我们在 Sensor 1 连接里向 retained_message 主题发送两条不一样的消息，且发送消息时勾选 Retain 选项。
然后，我们再在 Simple Demo 连接里订阅 retained_message 主题，订阅成功后将会收到 Sensor 1 发送的第二条保留消息，由此可见服务器只会保存一个主题下最后一条保留消息。
清除会话（Clean Session）
一般情况下 MQTT 客户端仅能接收到在线时其他客户端发布的消息，如果客户端离线再上线后将收不到离线期间的消息。但是当客户端使用固定的 Client ID，且连接参数 Clean Session 为 false 时，客户端离线后消息服务器可以为客户端保持一定量的离线消息，并在客户端再次上线后发送给客户端（且为客户端恢复下线前的订阅信息）。
本次演示使用的公共 MQTT 服务器设置的离线消息保存时间为 5 分钟，最大消息数为 1000 条，且不保存 QoS 0 消息。接下来我们创建一个 MQTT 3.1.1 版本的连接，并验证 QoS 1 情况下的离线会话。
MQTT5 中使用 CleanStart 与 SessionExpiryInterval 改进了 Clean Session。
如下图，创建一个名为 MQTT V3 的连接，Clean Session 设置为 false，MQTT 版本选择 3.1.1。
连接成功后订阅 clean_session_false 主题，且 QoS 设置为 1。
订阅成功后，点击右上角的断开连接按钮。
接下来创建一个名为 MQTT_V3_Publish 的连接，MQTT 版本同样设置为 3.1.1，连接成功后向 clean_session_false 主题发布三条消息。
然后选中 MQTT_V3 连接，点击连接按钮连接至服务器，将会成功接收到 3 条离线期间的消息。
遗嘱消息（Last Will）
MQTT 客户端向服务器发起连接请求时，可以设置是否发送遗嘱消息（Will Message）标志，和遗嘱消息主题（Topic）与内容（Payload）。设置了遗嘱消息消息的 MQTT 客户端异常下线时（客户端断开前未向服务器发送 DISCONNECT 消息），MQTT 消息服务器会发布该客户端设置的遗嘱消息。
如下图，我们创建一个名为 Last Will 的连接。
为了能快速看到效果，我们设置 Keep Alive 为 5 秒
Last-Will Topic 设置为 last_will
Last-Will QoS 设置为 1
Last-Will Retain 设置为 true
Last-Will Payload 设置为 offline
连接成功后，我们断开电脑网络 5 秒钟以上（模拟客户端异常下线），再打开网络。然后启动 Simple Demo 连接，并订阅 last_will 主题，将会收到 Last Will 连接设置的遗嘱消息。
至此，我们完成了对 MQTT 相关基础概念及其使用流程的讲解与演示，读者可以根据本文所学尝试上手使用 MQTT 协议，开始 MQTT 应用及服务开发，探索 MQTT 的更多高级应用。
全球领先的开源物联网基础设施软件供应商 2021-06-09 加入
面向 5G 和物联网市场的消息与流处理开源软件公司。
评论