全球物联网正在高速发展，专门针对低带宽和不稳定网络环境的物联网应用设计的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开源版。

dockerrun-d--nameemqx-p1883:1883-p8083:8083-p8084:8084-p8883:8883-p18083:18083emqx/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路径，例如：

chat/room/1

sensor/10/temperature

sensor/+/temperature

主题通过 / 分割层级，支持 +， # 通配符:

• +：表示通配一个层级，例如 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格式消息，并点击右侧最底部的发布按钮发送消息。

{

"msg":"17.2"

}

如下表示消息发送成功。

使用同样的步骤，在Sensor 2连接里向 sensor/2/temperature 主题发布如下JSON消息。

{
  "msg":"18.2"
}

将会看到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的更多高级应用。