轻松实现物联网通信的利器：MQTT网关神器——FluxMQ

Posted 陆陆起飞啦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了轻松实现物联网通信的利器：MQTT网关神器——FluxMQ相关的知识，希望对你有一定的参考价值。

FluxMQ—引领物联网新时代的高性能MQTT网关

随着物联网技术的快速发展，人们越来越意识到实时、可靠、安全的数据传输对于智能化的生产与生活的重要性。因此，市场对于高性能的物联网数据传输解决方案有着强烈的需求。FluxMQ正是为满足这一需求而诞生的一款高性能、可靠且易于使用的MQTT网关产品。

什么是FluxMQ？

产品介绍

FLuxMQ是一款基于java开发，支持无限设备连接的云原生分布式物联网接入平台。
FluxMQ基于Netty开发，底层采用Reactor3反应堆模型，具备低延迟，高吞吐量，百万-千万设备连接；方便企业快速构建其物联网平台与应用。

核心特性

JAVA开发
可构建物联网一体化平台产品，单机版整体打包，避免多语言组件多模块管理；
支持标准MQTT协议
完整支持MQTT3.x和MQTT5.0 协议标准；
支持Qos0，1，2的MQTT消息传递；
支持所有MQTT客户端和库；
规则引擎
灵活的规则模型配置，支持多种数据桥接和数据持久化；
数据安全
基于MQTT overTLS/SSL确保数据安全；
LDAP，PSK和X.509证书等多种身份认证；
灵活部署
支持物理机，容器，私有云，公有云中任何地方运行，不受位置限制，不受厂商锁定；
低成本
性能卓越，降低硬件需求成本；
支持买断和按需付费;

架构

功能概览

功能 说明
集群功能 支持MQTT集群
发布订阅 支持标准发布订阅
服务等级 QoS0，1，2
ACL 控制客户端发布订阅权限
流量控制 限制Broker接入流量
MQTT/MQTTS/WS协议 多协议支持
管理页面-连接管理 管理客户端状态，上下线
管理页面-ACL 访问授权
管理页面-订阅查询 查看设备订阅Topic
管理页面-规则引擎 转发消息
管理页面-云客户端 基于ws进行模拟测试
管理页面-动态认证 连接认证
管理页面-日志管理 标准接入日志
管理页面-监控管理 grafana监控方案
管理页面-数据源管理 多数据源
管理页面-告警功能 支持钉钉、微信、飞书
管理页面-协议解析 支持脚本解析处理payload

FluxMQ是一款专为物联网应用打造的MQTT网关产品，致力于为企业和开发者提供高效、安全的数据传输解决方案。基于业界领先的MQTT协议，FluxMQ具有低延迟、低功耗、高并发连接等优势，能够确保在各种应用场景下实现稳定、可靠的数据传输。

FluxMQ的核心特点

  • 高性能：FluxMQ采用了最新的消息处理技术和数据压缩算法，提供高吞吐量、低延迟的数据传输能力，为您的物联网应用带来卓越的性能体验。
  • 易于使用：FluxMQ提供了简洁明了的API接口和丰富的文档资源，无论您是物联网初学者还是经验丰富的开发者，都能轻松上手并快速实现项目部署。
  • 高安全性：FluxMQ支持TLS/SSL加密通信，确保数据在传输过程中的安全性。同时，提供了多种鉴权机制和访问控制策略，保护您的物联网应用免受未经授权的访问和攻击。
  • 高可靠性：FluxMQ具备强大的故障转移和负载均衡功能，确保在各种异常情况下保持稳定的运行。此外，FluxMQ还支持消息持久化，防止因意外断线等原因造成的数据丢失。
  • 广泛适用性：FluxMQ适用于各种规模的物联网应用场景，从智能家居、工业自动化到智能交通、智慧城市等，都能发挥其卓越性能，满足不同行业的需求。

FluxMQ——高性能压测报告

前言

所有压测机器采用16c32配置，压测过程中关闭连接日志，避免日志IO影响程序吞吐量

-Dname=$AppName  -Duser.timezone=Asia/Shanghai -Xmx28G -Xms28G -XX:MetaspaceSize=200M  -XX:+UseG1GC   -XX:MaxGCPauseMillis=200 -Xloggc:`$APP_HOME`/gc.log -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+DisableExplicitGC -verbose:gc

单机压测

仅仅部署一台MQTT节点进行压测

连接数压测

连接数 推送 报文大小 cpu 内存内存(最大使用)
1000000 1000/s --- 25% 9 G

广播压测

10W TPS
订阅 推送 报文大小 cpu 内存内存(最大使用)
50000 2/s 160B 20% 1.7G
50000 2/s 1024B 22% 1.9G

160B压测截图：

Dashboard
MQTT
jvm

1024B压测截图：

20W TPS
订阅 推送 报文大小 cpu 内存(最大使用)
50000 4/s 160B 23% 1.7G
50000 4/s 1024B 24% 1.9G

160B压测截图：

1024B压测截图：

40W TPS
订阅 推送 报文大小 cpu 内存(最大使用)
100000 4/s 160B 48% 15G
100000 4/s 1024B GC过长 已到瓶颈

160B压测截图：

1024B压测截图：

如果追求极致性能 还是有很大优化空间

桥接压测（KAFKA）

新建kafka数据源
新建规则转发
启用规则
10W TPS
连接 推送 报文大小 cpu 内存(最大使用)
50000 2/s 160B 22% 8G
50000 2/s 1024B 31% 10G

160B压测截图：

1024B压测截图：

15W TPS
连接 推送 报文大小 cpu 内存(最大使用)
50000 3/s 160B 31% 13G
50000 3/s 1024B 37% 15G

160B压测截图：

1024B压测截图：

20W TPS
连接 推送 报文大小 cpu 内存(最大使用)
50000 4/s 160B 35% 14G
50000 4/s 1024B 40% 16G

160B压测截图：

1024B压测截图：

对比EMQX

FluxMQ——物联网数据传输解决方案的不二选择

当今世界，物联网技术已经成为了推动智能化生产、智慧城市和智能交通等众多领域发展的重要引擎。在这个过程中，高性能的数据传输解决方案至关重要。FluxMQ以其高性能、易于使用、高安全性和高可靠性等优势，成为了物联网数据传输解决方案的不二选择。

FluxMQ的广泛适用性使其可以应用于各种规模的物联网应用场景，从智能家居、工业自动化到智能交通、智慧城市等。它不仅能够提供高效、安全的数据传输，还具备强大的故障转移和负载均衡功能，可以保证数据传输的稳定性和可靠性。

FluxMQ还提供了简洁明了的API接口和丰富的文档资源，无论您是物联网初学者还是经验丰富的开发者，都能轻松上手并快速实现项目部署。因此，我们相信FluxMQ将成为物联网应用开发者的得力助手，为他们提供更加便捷、高效、可靠的物联网数据传输解决方案。

如果您正在寻找一款可靠且易于使用的MQTT网关产品，那么FluxMQ绝对是您不可错过的选择。需要体验产品的请添加18510240791微信。

最后

系统演示地址

官网地址、点击查看（建设中）

网络编程——物联网利器MQTT通信协议详解

文章大纲

引言

书接上文网络编程——物联网利器MQTT通信协议详解（四） 系列文章链接：

6、MQTT控制包之PUBLISH包的结构

PUBLISH控制包可以从服务端发送给客户端也可以从客户端发送给服务端，来运送应用消息。

6.1 固定包头

PUBLISH的固定包头与其他有所不同，格式如下所示

Figure 3.10 - PUBLISH Packet fixed header
|Bit        |7  |6  |5  |4                  |3          |2  |1      |0
|byte 1     |MQTT Control Packet type (3)   |DUP flag   |QoS level  |RETAIN
|           |0  |0  |1  |1                  |X          |X  |X      |X
|byte 2     |Remaining Length
6.1.1 DUP

位于固定包头第1个字节的位 3 处（byte 1，bit 3）

  • 如果DUP标识被设置为0，则表示服务端或客户端第一次尝试发送PUBLISH包。换言之，所有QoS为0的消息DUP标识必须也设置为0。
  • 如果DUP标识被设置为1，则表示可能是在重复发送早前尝试发送过的数据包。换言之，当客户端或是服务端试图重新发送PUBLISH包的时候，DUP标识必须被设置为1。

服务端收到带有DUP值的PUBLISH包，当服务端发送这个PUBLISH包给订阅者的时候，DUP的值不会传播。发送的PUBLISH包的DUP标识独立于收到的PUBLISH包的DUP标识，它的值只由是否是重复发送决定

接收方在收到DUP标识设置为1的控制包时，不能当作已经收到较早的控制包。DUP标识只作用于控制包本身，而不是它包含的应用程序消息。使用QoS 1时，有可能为客户获得发布包DUP标志设置为0，包含一个已经收到过的应用程序的重复信息，但是有不同的数据包标识。

6.1.2 QoS

位于固定包头第1个字节的位 2–1（byte 1，bits 2-1）表明了应用消息传送的质量。

|QoS value |Bit 2 |bit 1 |Description|
|—|----|—|
|0 |0 |0 |At most once delivery|
|1 |0 |1 |At least once delivery|
|2 |1 |0 |Exactly once delivery|
|- |-1 |1 |Reserved – must not be used|

PUBLISH包必定不能将QoS的两个bit都设为1（即QoS value不能设置为3,二进制 11）。如果服务端或客户端收到的PUBLISH包中QoS的两个bit都设置为1的话，必须关闭网络连接。

6.1.3 RETAIN

位于固定包头的**第1个字节的位0 **（byte 1，bit 0），RETAIN标识被设置为1，在一个从客户端发送到服务端的PUBLISH包中，服务端必须存储应用消息和QoS，以便可以发送给之后订阅这个话题的订阅者。当一个新的订阅发生，最后一个保留的消息，如果有的话，而且匹配订阅话题，必须发送给订阅者。

  • 如果服务端收到一个QoS 0并且RETAIN标识设置为1的消息，它必须清空之前为这个话题保存的所有消息。服务端应该存储新的QoS 0的消息作为这个话题新的保留消息，但是也可以选择在任何时候清空保留消息——如果这样做了，那这个话题就没有保留消息了；
  • 如果消息是作为客户端新的订阅的结果从服务端发送PUBLISH包给客户端，服务端必须将RETAIN标识设置为1，当PUBLISH包发送给客户端，必须设置RETAIN为0，因为不管标识如何设置，它都是已订阅的消息。

RETAIN标识被设置为1而且载荷包含0个字节的PUBLISH包也会被服务端像平常一样处理，发送给匹配话题的客户端。而且所有这个话题下的保留消息都会被清除，这个话题接下来的订阅者都不会收到保留消息

"平常"意味着现存客户端收到的消息RETAIN标识都没有设置。0字节的保留消息一定不会作为保留消息存储在服务端

如果RETAIN标识位0，在客户端发送给服务端的PUBLISH包中，服务端一定不能存储这个消息，也一定不能删除或替换任何已存在的保留消息

6.1.4、Remaining Length

剩余长度为可变包头的长度加上载荷的长度

6.2 可变包头

可变包头按顺序包含以下字段：话题名，包唯一标识。

6.2.1 话题名

话题名指载荷数据发布的信息通道，话题名必须是PUBLISH包可变包头的第一个字段且是以是UTF-8编码字符串。PUBLISH包中的话题名一定不能包含通配符，服务端发送给客户端的PUBLISH包中的话题名必须匹配订阅话题过滤器。但是因为服务端允许重写话题名，所以可能话题名和最初的PUBLISH包不同。

6.2.2 包唯一标识

包唯一标识只在QoS等级为1或2的PUBLISH包中，包标唯一标识的更多信息见2.1节。

6.3 载荷

载荷包含了发布的应用消息，内容和格式由应用决定。载荷的长度可以由固定包头中的Remaining Length减去可变包头长度得到，也适用于载荷长度为零的PUBLISH包。

6.4 响应

PUBLISH包的接收方必须根据，由PUBLISH包的QoS来决定如何响应。

QoS LevelExpected Response
QoS 0None
QoS 1PUBACK Packet
QoS 2PUBREC Packet

6.5 行为

为了分发给匹配订阅的客户端，客户端需要使用PUBLISH包先发送应用消息给服务端，再由服务端使用PUBLISH包发送应用消息给每一个匹配订阅的客户端。当客户端通过带有通配符的话题过滤器订阅的时候，订阅之间可能会有重叠，以至于发布的消息会匹配多个过滤器。这种情况下，服务端必须使用客户端所有匹配的订阅中的最大的QoS来派发消息[且服务端可能会发送多个消息副本，每个匹配的订阅使用相应的QoS发送一次。当收到PUBLISH包的时候，接收者的行为依赖于QoS等级。

7、MQTT控制包之PUBACK包的结构

发布确认PUBACK包，用于响应QoS等级为1 的PUBLISH包，无载荷。

7.1、固定包头

PUBACK包的固定包头结构与其他包头一致，其剩余长度为可变包头的长度即2。

7.2、可变包头

包含需要确认的那个PUBLISH包的包唯一标识。

Figure3.13 - PUBACK Packet variable header

|Bit        |7 |6 |5 |4 |3 |2 |1 |0
|byte 1     |Packet Identifier MSB
|byte 2     |Packet Identifier LSB

8、MQTT 控制包之PUBREC 包

发布收到PUBREC包，用于响应QoS等级为2 的PUBLISH包，是QoS 2协议交换的第二个包，无载荷。

8.1、固定包头

PUBREC包的固定包头结构与其他包头一致，其剩余长度为可变包头的长度即2。

8.2、可变包头

包含需要确认的那个PUBLISH包的包唯一标识。

9、MQTT 控制包之PUBREL 包(收到QoS 2的发布)

发布完成PUBREL包，用于响应PUBREC包，是QoS 2协议交换的第三个包，无载荷。

9.1、固定包头

PUBREL控制包的固定包头的位3，2，1，0是保留位且必须被分别设置为0，0，1，0。服务端必须将其他值作为畸形，并且关闭网络连接。


|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (6)   |Reserved
|           |0      |1      |1      |0      |0      |0      |1      |0
|byte 2     |Remaining Length (2)
|           |0      |0      |0      |0      |0      |0      |1      |0

其剩余长度为可变包头的长度即2。

9.2、可变包头

包含需要确认的那个PUBREC包的包唯一标识。

10、MQTT 控制包之PUBCOMP包（QoS 2发布接收）

发布PUBCOMP包，用于响应PUBREL包，是QoS 2协议交换的第四个也是最后一个包，无载荷。

10.1、固定包头

PUBREC包的固定包头结构与其他包头一致，其剩余长度为可变包头的长度即2。

10.2、可变包头

包含需要确认的那个PUBREL包的包唯一标识。

11、MQTT 控制包之SUBSCRIBE包

SUBSCRIBE包从客户端发送到服务端创建一个或多个订阅,每个订阅注册客户端感兴趣的一个或多个话题。服务端向客户端发送PUBLISH包来分发匹配订阅的应用消息。SUBSCRIBE包也（为每个订阅）指定服务端发送给客户端的应用消息的最大QoS。

11.1、固定包头

SUBSCRIBE控制包的固定包头的3，2，1，0位是保留位且必须设置为0，0，1，0。服务端必须把其他值作为畸形对待，然后关闭网络连接。

|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (8)   |Reserved
|           |1      |0      |0      |0      |0      |0      |1      |0
|byte 2     |Remaining Length

其剩余长度为可变包头长度（即2）加上载荷的长度。

11.2、可变包头

可变包头包含包唯一标识，其他参见2节MQTT可变包头。

11.3、载荷

SUBSCRIBE包的载荷包含了话题过滤器的列表（指示客户端想要订阅的主题），主题过滤器必须是UTF-8编码字符串。服务端应该支持包含通配符的话题过滤器。如果选择不支持带有通配符的话题过滤器，就必须拒绝所有带有通配符过滤器的订阅。另外每个过滤器后面都带有一个字节的QoS（指定了服务端发送给客户端应用消息的最大QoS等级）。所以SUBSCRIBE包的载荷至少包含一个成对的话题过滤器/QoS且以话题过滤器/QoS对依次连续被封装，没有载荷的SUBSCRIBE包是违反协议的。

|Description    |7 |6 |5 |4 |3 |2 |1 |0
|Topic Filter
|byte 1         |Length MSB
|byte 2         |Length LSB
|bytes 3..N     |Topic Filter
|Requested QoS
|               |Reserved         |QoS
|byte N+1       |0 |0 |0 |0 |0 |0 |X |X

11.4、响应

当服务端收到客户端发来的SUBSCRIBE包，服务端必须响应一个包含与相应SUBSCRIBE包相同的包唯一标识SUBACK包。服务端在发送SUBACK包之前，就可以开始发送订阅的PUBLISH包。如果服务端收到一个SUBSCRIBE包，其中包含的话题过滤器与一个已经存在的话题过滤器完全相同，服务端必须用新的订阅替换已经存在的订阅。如果新的订阅中的话题过滤器与之前订阅中的完全一样，但是最大QoS的值可能不同。所有保存的符合该话题过滤器的消息必须被重发，但是发布流一定不能被打断。如果话题过滤器与已存在订阅的过滤器都不相同，新的订阅会被创建，并且所有的匹配的保留消息都会被发送。如果服务端收到的SUBSCRIBE包包含多个话题过滤器，必须像顺序的收到多个SUBSCRIBE包一样处理它，然后再把所有的响应合并为一个SUBACK响应从服务端发送到客户端的SUBACK包中，每一个话题过滤器/QoS对都有一个对应的返回码。返回码必须是这次订阅的最大QoS，否则就订阅失败。服务端可能会授予一个较低等级的最大QoS，相比较于订阅者要求的。订阅响应的载荷消息的QoS必须是原始发布消息的最小QoS，而且是服务端授予的最大QoS。服务端可以给订阅者发布多个消息拷贝，来应对原始消息使用QoS 1发布，最大QoS为QoS 0的情况。

12、MQTT控制包之SUBACK

订阅确认SUBACK包是从服务端发送给客户端用来确认收到并处理了SUBSCRIBE包。SUBACK包包含了返回码的列表，指定了SUBSCRIBE包中的每个订阅的最大QoS等级。

12.1、固定包头


|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (9)   |Reserved
|           |1      |0      |0      |1      |0      |0      |0      |0
|byte 2     |Remaining Length

其可变长度为可变包头的长度（2字节）再加上载荷的长度。

12.2、可变包头

可变包头包含了需要确认的SUBSCRIBE包的包唯一标识

12.3、载荷

载荷包含了返回码的列表。每个返回码对应SUBSCRIBE包中需要被确认的一个话题过滤器。SUBACK包中的返回码的顺序必须匹配SUBSCRIBE包中的话题过滤器的顺序

|Bit     |7 |6 |5 |4 |3 |2 |1 |0
|        |Return Code
|byte 1  |X |0 |0 |0 |0 |0 |X |X

允许的返回码：

  • 0x00 - 成功 - 最大QoS为0
  • 0x01 - 成功 - 最大QoS为1
  • 0x02 - 成功 - 最大QoS为2
  • 0x80 - 失败

除了0x00,0x01,0x02,0x80之外的SUBACK返回码是保留的且不允许使用。

13、 UNSUBSCRIBE

退订话题UNSUBSCRIBE包从客户端发往服务端用来退订话题。

13.1、固定包头

UNSUBSCRIBE控制包固定包头的3，2，1，0位是预留的，而且必须分别被设置为0，0，1，0。服务端必须把其他值作为畸形且关闭网络连接。


|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (10)  |Reserved
|           |1      |0      |1      |0      |0      |0      |1      |0
|byte 2     |Remaining Length

其剩余长度为可变包头的长度（即2字节）加上载荷的长度。

13.2、可变包头

可变包头包含了包唯一标识。

|Bit        |7 |6 |5 |4 |3 |2 |1 |0
|byte 1     |Packet Identifier MSB
|byte 2     |Packet Identifier LSB

13.3、载荷

UNSUBSCRIBE包包含了客户端希望退订的话题过滤器列表，UNSUBSCRIBE包的载荷必须包含至少一个话题过滤器，没有载荷的UNSUBSCRIBE包是违反协议的。

13.4、响应

UNSUBSCRIBE包中的话题过滤器（无论是否包含通配符），都必须逐个字符的与客户端在服务器中的现有订阅集合做比较。如果过滤器匹配成功，那么删除相应的订阅，否则就不处理。

如果服务端删除了订阅：

  • 必须停止追加新的派发给客户端的消息[MQTT-3.10.4-2]。
  • 必须完成所有已经开始发送给客户端的QoS 1或QoS 2消息的派发。
  • 可以继续发送派发消息队列中已经存在的消息给客户端。

服务端必须发送UNSUBACK包来响应UNSUBSCRIBE，UNSUBACK包必须和UNSUBSCRIBE包有相同的包唯一标识。即使没有话题订阅被删除，服务端也必须响应一个UNSUBACK。如果服务端收到一个UNSUBSCRIBE包，包含多个话题过滤器，服务端必须像按顺序收到多个UNSUBSCRIBE包一样来处理，但是只发送一个UNSUBACK包来响应。

14、MQTT控制包之 UNSUBACK

退订确认UNSUBACK包从服务端发往客户端来确认收到UNSUBSCRIBE包，无载荷。

14.1 固定包头

Figure 3.31 – UNSUBACK Packet fixed header

|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (11)  |Reserved
|           |1      |0      |1      |1      |0      |0      |0      |0
|byte 2     |Remaining Length (2)
|           |0      |0      |0      |0      |0      |0      |1      |0

其剩余长度为可变包头的长度即2字节。

14.2 可变包头

可变包头包含了需要确认的UNSUBSCRIBE包的包唯一标识。

Figure 3.32 – UNSUBACK Packet variable header

|Bit        |7 |6 |5 |4 |3 |2 |1 |0
|byte 1     |Packet Identifier MSB
|byte 2     |Packet Identifier LSB

15、MQTT控制包之PINGREQ

PING请求PINGREQ包从客户端发往服务端，可以用来：

  • 在没有其他控制包从客户端发送给服务端的时候，告知服务端客户端的存活状态。

  • 请求服务端响应，来确认服务端是否存活。

  • 确认网络连接的有效性。

这个包在Keep Alive处理中用到。

15.1 固定包头

Figure 3.33 – PINGREQ Packet fixed header

|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (12)  |Reserved
|           |1      |1      |0      |0      |0      |0      |0      |0
|byte 2     |Remaining Length (0)
|           |0      |0      |0      |0      |0      |0      |0      |0

其剩余长度为0，既无可变包头，也无载荷。

15.2 响应

服务端必须发送PINGRESP包响应PINGREQ包。

16、MQTT控制包之 PINGRESP

PING响应 PINGRESP包从服务端发送给客户端来响应PINGREQ包代表服务端是存活的。

3.13.1 固定包头

|Figure 3.34 – PINGRESP Packet fixed header

|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (13)  |Reserved
|           |1      |1      |0      |0      |0      |0      |0      |0
|byte 2     |Remaining Length (0)
|           |0      |0      |0      |0      |0      |0      |0      |0

其剩余长度为0，既无可变包头，也无载荷。

17、MQTT控制包之DISCONNECT

断开连接通知 DISCONNECT包是客户端发给服务端的最后一个控制包表示客户端正在干净利索的断开连接。

17.1 固定包头

|Figure 3.35 – DISCONNECT Packet fixed header

|Bit        |7      |6      |5      |4      |3      |2      |1      |0
|byte 1     |MQTT Control Packet type (14)  |Reserved
|           |1      |1      |0      |0      |0      |0      |0      |0
|byte 2     |Remaining Length (0)
|           |0      |0      |0      |0      |0      |0      |0      |0

其剩余长度为0，既无可变包头，也无载荷。

17.2 响应

客服端发送DISCONNECT包之后：

  • 必须关闭网络连接[MQTT-3.14.4-1]。
  • 不允许在这个网络连接上再发送任何控制包。

服务端收到DISCONNECT包：

  • 必须丢弃所有和当前连接有关的Will Message，不要发布。
  • 应该关闭网络连接，如果客户端还没有这么做。

六、MQTT 常见Q&A

QuestionAnswer
MQTT 协议默认使用的端口号？1883
没有Broker可以使用MQTT协议吗？不能，必须搭建或者借用其他公共的Broker
多个客户端是否可以发布到同一Topic？可以
是否可以知道发布Message的客户端的具体身份？默认不行，除非在Topic或者Payload中主动标识
当发布的Topic无人订阅Broker 会怎么处理？默认忽略掉，丢弃。
是否可以订阅一个可能无任何客户端发布的主题？可以，但无意义。
Message是否存储在Broker上？是的，但是只是临时性的，一旦被转发给所有订阅者，它们就会被丢弃，但Retained Messages 除外。
什么是Retained Messages？发布Message时，可以让Broker存储上次发布的消息，若最后一条Message没被订阅者处理，Broker将在订阅者订阅时主动转发最近上一次的Message，MQTT只保留1条消息。
如何删除或删除Retained Messages？用同一个Topic 发布一个空白（Payload 字节为0）的Retained Message
不同的QOS是否对Retained Messages影响？没有

MQTT的应用，未完待续…

以上是关于轻松实现物联网通信的利器：MQTT网关神器——FluxMQ的主要内容，如果未能解决你的问题，请参考以下文章

网络编程——物联网利器MQTT通信协议详解

网络编程——物联网利器MQTT通信协议详解

物联网网关开发：基于MQTT消息总线的设计过程(下)

物联网网关开发：基于MQTT消息总线的设计过程(下)

为什么工业物联网平台要配备MQTT网关?|

边缘计算网关 物联网时代又一通信神器