MQTT 这个协议我第一次接触是在一个远程环境监测项目里。当时设备分布在好几个不同的物理位置网络条件参差不齐有的地方信号弱到 HTTP 请求十次有三次超时。后来换成 MQTT同样的硬件、同样的网络消息到达率直接上了一个台阶。从那以后但凡遇到设备间通信、数据采集、远程控制这类场景我基本都会优先考虑 MQTT。这篇文章想聊的是我在实际项目中积累下来的 MQTT 核心机制理解——发布订阅模型到底怎么运转、QoS 等级怎么选才不浪费资源也不丢消息、遗嘱消息在什么场景下能救命、持久会话又解决了什么问题。内容会从基础概念一路讲到实战配置中间穿插我在真实项目里踩过的坑和总结出来的参数选择逻辑。不管你是刚接触物联网通信的开发者还是已经在用 MQTT 但想搞清楚底层机制的老手应该都能从里面找到对自己有用的东西。1. 发布订阅模型为什么它比请求响应更适合物联网1.1 从 HTTP 的痛点说起大部分开发者最早接触的网络通信模型是请求响应式的比如 HTTP。客户端发一个请求服务器返回一个响应一问一答逻辑清晰。这种模式在 Web 场景下工作得很好但放到物联网环境里就有点力不从心了。我做过一个温度监控系统最初用 HTTP 轮询的方式每个传感器节点每隔几秒向服务器发一次数据上报请求。看起来没问题但设备数量一多问题就暴露了。一百个节点、每五秒轮询一次服务器每秒要处理二十个请求这还只是小规模。如果是一千个节点呢每秒两百个请求而且大部分请求携带的数据可能根本没变化。更麻烦的是反向控制——服务器想给某个设备下发指令只能等设备下次轮询时才能捎带回去实时性完全没法保证。发布订阅模型从根本上改变了这个局面。它引入了一个中间角色——消息代理Broker发布者和订阅者之间不再直接通信而是通过 Broker 进行消息路由。发布者只管把消息发到某个主题Topic上订阅者只管从自己关心的主题上收消息双方互相不知道对方的存在。1.2 发布订阅的核心角色拆解整个模型里有三个关键角色理解它们的分工是理解 MQTT 的基础。发布者Publisher是消息的生产方。它不需要知道谁在听只需要把消息按照约定的主题格式发给 Broker。比如一个温度传感器它可能每隔几秒向sensors/room1/temperature这个主题发布一条包含当前温度值的消息。订阅者Subscriber是消息的消费方。它向 Broker 表达自己对哪些主题感兴趣可以精确订阅一个主题也可以用通配符订阅一批主题。比如一个监控大屏可能订阅sensors//temperature这样所有房间的温度数据都能收到。消息代理Broker是中间人负责接收发布者的消息并根据订阅关系把消息转发给对应的订阅者。Broker 是整个系统的核心它的性能和稳定性直接决定了整个通信链路的质量。这种解耦带来的好处非常明显。发布者和订阅者在时间上不需要同时在线——发布者发消息的时候订阅者可能离线等订阅者上线后仍然能收到前提是用了持久会话。在空间上也不需要知道对方的地址——不需要配置 IP、端口只需要约定好主题格式。在数量上更是灵活——一个发布者可以对应零个、一个或多个订阅者反过来也一样。1.3 主题设计与通配符的实战用法主题是 MQTT 里最核心的概念之一它决定了消息的路由规则。主题用斜杠/分隔层级比如home/livingroom/light/status。这里有几个实战中总结出来的设计原则。第一层级从大到小从左到右。先写大范围再写具体对象比如factory/workshop1/machine3/vibration这样用通配符订阅的时候更容易控制范围。第二避免用中文和特殊字符。虽然协议本身没有强制要求但实际部署中中文主题在某些 Broker 实现上会出现编码问题排查起来很头疼。第三不要以$开头。$开头的主题在 MQTT 里有特殊用途比如$SYS/是 Broker 自己发布系统信息的主题普通消息用$开头容易冲突。通配符有两种用好了能大幅简化订阅逻辑。匹配单层。比如home//temperature能匹配home/livingroom/temperature和home/bedroom/temperature但匹配不了home/livingroom/sensor1/temperature。#匹配多层必须放在主题末尾。比如home/#能匹配home下面所有层级的主题。注意#只能出现在主题的最后home/#/temperature这种写法是非法的。可以出现在任意层级但只能匹配一层。我踩过一个坑早期设计主题时用了device/data这种扁平结构后来设备类型多了想按类型筛选就非常麻烦。后来改成device/{type}/{id}/data的三层结构用device/sensor//data就能一次性订阅所有传感器的数据灵活多了。主题设计这件事前期多花十分钟想清楚后期能省十个小时的维护时间。2. QoS 等级消息可靠性的三档选择2.1 三个等级到底有什么区别QoSQuality of Service是 MQTT 保证消息可靠性的机制分三个等级。很多人知道有这三个等级但说不清楚它们的具体行为差异导致选型时要么过度保守浪费资源要么过于激进丢消息。QoS 0——最多一次。发布者发出去就不管了Broker 收到就转发转发完就忘。消息可能丢失但绝不会重复。适合那些偶尔丢一条也无所谓的场景比如环境温度上报丢一个数据点对整体趋势判断影响不大。QoS 1——至少一次。发布者发出消息后等待 Broker 的 PUBACK 确认如果没收到确认就重发。这保证了消息不会丢但可能重复——比如 Broker 确实收到了消息但 PUBACK 在返回途中丢了发布者会重发订阅者就会收到两条一样的消息。适合不能丢但能容忍重复的场景比如开关控制指令重复执行一次开灯操作结果是一样的。QoS 2——恰好一次。通过四次握手PUBLISH → PUBREC → PUBREL → PUBCOMP确保消息既不丢失也不重复。这是可靠性最高的等级但开销也最大消息往返次数最多。适合那些重复会造成严重后果的场景比如计费系统、医疗设备的数据上报。2.2 消息传递中的 QoS 降级规则这里有一个容易被忽略的细节消息最终以发布和订阅中较低的 QoS 等级传递。举个例子发布者用 QoS 2 发布消息但订阅者订阅时用的是 QoS 0那么消息实际以 QoS 0 传递给这个订阅者。反过来发布者用 QoS 0订阅者用 QoS 2消息也只能以 QoS 0 传递。这个规则的原因很简单QoS 0 的发布者根本没有保存消息副本用于重发Broker 收到什么就只能转发什么没法凭空提升可靠性。所以如果你需要某个主题的消息保证 QoS 2必须发布端和订阅端都设置为 QoS 2。2.3 不同场景下的 QoS 选型实战选 QoS 等级的核心原则是根据业务对丢消息和重复消息的容忍度来决定而不是无脑选最高。场景推荐 QoS理由环境传感器周期上报0数据量大偶尔丢点不影响趋势分析设备状态变更通知1不能丢重复通知可以接受远程控制指令1指令不能丢重复执行通常幂等计费/交易数据2重复会造成财务错误心跳保活0丢了下一轮马上补上我在一个智能农业项目里做过对比测试。大棚里有两百多个传感器节点最初全部用 QoS 1Broker 的 CPU 占用率一直在 60% 以上。后来把纯数据采集类的主题降到 QoS 0只保留控制指令用 QoS 1CPU 占用率直接降到 25% 左右而业务上并没有感觉到数据质量下降。这个经验告诉我QoS 选型要精细化不要一刀切。实操心得如果你的 Broker 负载很高先检查是不是所有主题都用了高 QoS。把那些丢了也无所谓的数据流降到 QoS 0往往能释放大量资源。3. 遗嘱消息设备掉线时的最后一道防线3.1 遗嘱消息的工作机制遗嘱消息Last Will and Testament是 MQTT 里一个非常实用但经常被忽视的功能。它的逻辑是客户端在连接 Broker 的时候可以预先设置一条遗嘱——包括遗嘱主题、遗嘱内容和遗嘱 QoS。当客户端异常断开连接时注意是异常断开不是主动断开Broker 会自动把这条遗嘱消息发布出去。什么算异常断开网络中断、设备断电、程序崩溃导致 TCP 连接意外断开这些都会触发遗嘱消息。而客户端主动发送 DISCONNECT 报文正常断开时Broker 会丢弃遗嘱消息不会发布。这个机制解决了一个很实际的问题如何及时知道一个设备掉线了。在没有遗嘱消息之前我们通常靠心跳超时来判断但心跳超时时间设短了容易误判设长了发现掉线又太慢。遗嘱消息让设备在连接建立时就留好遗言一旦掉线 Broker 立刻发布监控系统能第一时间收到通知。3.2 遗嘱消息的配置参数详解设置遗嘱消息需要在 CONNECT 报文中携带以下信息Will Topic遗嘱消息发布到哪个主题比如devices/sensor1/statusWill Payload遗嘱消息的内容通常是一个表示离线的字符串或 JSON比如{status:offline}Will QoS遗嘱消息的 QoS 等级建议用 1确保监控端能收到Will Retain遗嘱消息是否保留建议设为 true这样新上线的监控端也能立即看到设备离线状态配置遗嘱消息的时机是在建立连接的时候以 Python 的 paho-mqtt 库为例import paho.mqtt.client as mqtt client mqtt.Client(client_idsensor1) client.will_set( topicdevices/sensor1/status, payload{status:offline,ts: str(int(time.time())) }, qos1, retainTrue ) client.connect(broker.example.com, 1883, 60)这段代码的意思是如果 sensor1 这个客户端异常断开Broker 会向devices/sensor1/status发布一条 QoS 1 的保留消息内容是离线状态和时间戳。3.3 遗嘱消息与保留消息的配合使用遗嘱消息单独用效果有限和保留消息Retained Message配合才能发挥最大价值。保留消息的机制是Broker 会为每个主题保存最后一条设置了 retain 标志的消息。当有新的订阅者订阅这个主题时Broker 会立即把这条保留消息推送给它。这意味着监控端不需要等设备下次发布消息才能知道状态一订阅就能拿到最新值。把遗嘱消息设为 retain效果就是设备离线时 Broker 发布一条保留的离线消息之后任何新订阅这个主题的监控端都会立刻收到设备离线的通知。设备重新上线后正常发布一条 retain 的在线消息覆盖掉之前的离线消息新订阅者看到的就是在线状态。这个组合我在多个项目里用过效果很稳。有一个细节需要注意设备正常上线后一定要主动发布一条 retain 的在线状态消息否则 Broker 上保留的还是上次的离线消息新订阅者会误以为设备还没上线。注意遗嘱消息的延迟取决于 Broker 检测到连接断开的时间。如果 Broker 的 keepalive 设置是 60 秒那么最坏情况下设备掉线 60 秒后遗嘱消息才会发布。对实时性要求高的场景可以适当缩短 keepalive 时间但会增加心跳包的数量。4. 持久会话让离线设备不再错过消息4.1 会话状态到底保存了什么MQTT 的持久会话Persistent Session解决的是这样一个问题订阅者离线期间发布者发布的消息怎么办默认情况下Clean Session true每次客户端连接 Broker 都会创建一个全新的会话之前的订阅关系全部丢失离线期间的消息也不会保存。客户端重新连接后需要重新订阅而且只能收到重新订阅之后发布的消息。持久会话Clean Session false则不同。Broker 会为客户端保存以下状态客户端的订阅关系重新连接后自动恢复不需要重新订阅离线期间收到的 QoS 1 和 QoS 2 消息等客户端上线后推送未完成的 QoS 1 和 QoS 2 消息传输状态比如已发送但未确认的消息这里有一个关键点只有 QoS 1 和 QoS 2 的消息才会被保存。QoS 0 的消息在客户端离线时会被直接丢弃因为 QoS 0 本身就不保证送达。4.2 Clean Session 参数的取舍逻辑Clean Session 设 true 还是 false取决于你的业务场景。设 true 的场景客户端每次连接都是全新的开始不需要历史消息。比如一个临时的调试工具连上去看看当前数据就行不需要知道之前发生了什么。或者一个每次启动都重新订阅所有主题的客户端反正订阅逻辑是固定的重新订阅也不费事。设 false 的场景客户端可能频繁断线重连而且断线期间的消息不能丢。比如一个移动网络下的车载终端过隧道时信号中断出来后需要补收中断期间的控制指令。或者一个偶尔休眠的传感器醒来后需要收到休眠期间下发的配置更新。这里有一个容易踩的坑持久会话会占用 Broker 的存储资源。如果大量客户端都设了 Clean Session false而且长期不连接Broker 上会积累大量未投递的消息和会话状态。所以设持久会话的同时要关注 Broker 的会话过期配置。MQTT 5.0 引入了 Session Expiry Interval 参数可以设置会话在客户端断开后多久过期超时自动清理。MQTT 3.1.1 没有这个参数需要 Broker 端配置或手动清理。4.3 持久会话与消息堆积的实战处理我在一个远程抄表项目里遇到过持久会话导致的消息堆积问题。项目里有几千个电表每个电表每小时上报一次数据用的是 QoS 1 持久会话。正常情况下没问题但有一次 Broker 升级维护停了两个小时恢复后所有电表同时重连Broker 需要把积压的消息全部推送给订阅端瞬间压力巨大导致部分消息投递超时。后来我们做了几个优化。第一把数据上报的 QoS 从 1 降到 0因为抄表数据丢一两个点可以接受下次上报会带上累计值。第二对确实需要持久会话的客户端设置了合理的会话过期时间避免长期不连接的客户端占用资源。第三在 Broker 端限制了单个客户端的最大积压消息数超过阈值就丢弃最旧的消息防止无限堆积。这些调整之后系统稳定了很多。持久会话是个好功能但要用在合适的地方并且配合合理的清理策略。5. 从零搭建 MQTT 环境与客户端实操5.1 Broker 选型与搭建自己搭建 MQTT 环境第一步是选 Broker。目前主流的开源 Broker 有几个选择各有侧重。Mosquitto是最轻量的选择安装包小配置简单适合快速搭建测试环境和小规模生产环境。它的缺点是集群能力弱单机性能有上限。EMQX是国内用得比较多的选择支持大规模集群有 Web 管理界面MQTT 5.0 支持完善。功能全但相对重一些适合中大规模部署。RabbitMQ通过插件支持 MQTT如果你已经在用 RabbitMQ 做消息队列可以顺便把 MQTT 也接进来不用额外维护一套 Broker。但它的 MQTT 支持不如专用 Broker 那么原生。用 Docker 起一个 Mosquitto 是最快的验证方式docker run -d --name mosquitto \ -p 1883:1883 \ -p 9001:9001 \ -v /path/to/mosquitto.conf:/mosquitto/config/mosquitto.conf \ eclipse-mosquitto配置文件里至少要设置监听端口和是否允许匿名连接listener 1883 allow_anonymous true listener 9001 protocol websockets生产环境一定要把allow_anonymous设为 false并配置用户名密码或证书认证。我见过不少因为 Broker 匿名开放导致的安全问题这个口子不能开。5.2 客户端工具的选择与使用调试 MQTT 少不了客户端工具。MQTTX是我用得最多的图形化客户端跨平台支持 MQTT 5.0界面清爽订阅和发布在同一个窗口里就能完成调试起来很顺手。下载安装后新建连接填 Broker 地址和端口点连接就能用。命令行工具mosquitto_pub和mosquitto_sub适合脚本化操作和快速验证# 订阅主题 mosquitto_sub -h broker.example.com -t sensors//temperature -q 1 -v # 发布消息 mosquitto_pub -h broker.example.com -t sensors/room1/temperature -m 25.6 -q 1-v参数会同时打印主题名和消息内容调试多主题订阅时很有用。-q指定 QoS 等级。如果你用 JMeter 做压力测试需要下载 MQTT 插件。JMeter 本身不带 MQTT 支持装好插件后可以创建 MQTT Connect、MQTT Pub、MQTT Sub 等 Sampler模拟大量客户端并发连接和收发消息用来评估 Broker 的承载能力。5.3 代码实战Python 客户端完整示例下面是一个完整的 Python MQTT 客户端示例包含了连接、遗嘱消息设置、订阅、发布和持久会话的配置import paho.mqtt.client as mqtt import time import json BROKER broker.example.com PORT 1883 CLIENT_ID device_sensor_001 def on_connect(client, userdata, flags, rc): if rc 0: print(连接成功) client.subscribe(commands/device_sensor_001/#, qos1) else: print(f连接失败返回码{rc}) def on_message(client, userdata, msg): print(f收到消息 - 主题{msg.topic}内容{msg.payload.decode()}QoS{msg.qos}) if msg.topic commands/device_sensor_001/reboot: print(执行重启操作...) def on_disconnect(client, userdata, rc): print(f断开连接返回码{rc}) if rc ! 0: print(异常断开尝试重连...) client mqtt.Client(client_idCLIENT_ID, clean_sessionFalse) client.username_pw_set(username, password) client.will_set( topicfdevices/{CLIENT_ID}/status, payloadjson.dumps({status: offline, ts: int(time.time())}), qos1, retainTrue ) client.on_connect on_connect client.on_message on_message client.on_disconnect on_disconnect client.connect(BROKER, PORT, keepalive60) client.loop_start() client.publish( topicfdevices/{CLIENT_ID}/status, payloadjson.dumps({status: online, ts: int(time.time())}), qos1, retainTrue ) try: while True: temperature 25.0 client.publish( topicfsensors/{CLIENT_ID}/temperature, payloadjson.dumps({value: temperature, ts: int(time.time())}), qos0 ) time.sleep(5) except KeyboardInterrupt: client.publish( topicfdevices/{CLIENT_ID}/status, payloadjson.dumps({status: offline, ts: int(time.time())}), qos1, retainTrue ) client.disconnect() client.loop_stop()这段代码里有几个值得注意的点。clean_sessionFalse开启了持久会话客户端断线重连后订阅关系自动恢复。遗嘱消息设置了 retain设备异常掉线后监控端能立即感知。正常退出时主动发布离线状态并调用disconnect()这样 Broker 不会触发遗嘱消息而是用我们主动发布的离线消息覆盖。loop_start()启动了一个后台线程处理网络循环主线程可以继续做其他事情。5.4 嵌入式设备接入的注意事项在 STM32 这类资源受限的设备上跑 MQTT和 PC 端有几个明显的差异。内存管理要格外小心。MQTT 客户端库需要缓冲区来存放待发送和待接收的报文STM32 上 RAM 有限缓冲区不能设太大。一般 QoS 0 的消息缓冲区设 256 字节到 512 字节就够了QoS 1 和 QoS 2 因为要保存消息副本用于重发需要更大一些。网络稳定性处理要更健壮。嵌入式设备经常遇到网络抖动TCP 连接可能无声无息地断了。除了 MQTT 层面的 keepalive建议在应用层再加一层心跳检测比如每隔 30 秒发布一条心跳消息如果连续几次发布失败就主动重连。4G 模块的 AT 指令和 MQTT 库的配合也需要调试。有些 4G 模块自带 MQTT AT 指令可以直接用模块内置的 MQTT 功能省去在 MCU 上跑 MQTT 库的开销。但模块内置的 MQTT 功能通常比较基础QoS 支持和遗嘱消息可能不完整选型时要确认清楚。6. 常见问题排查与避坑指南6.1 连接类问题速查现象可能原因排查方法连接被拒绝返回码 1协议版本不匹配确认客户端和 Broker 的 MQTT 版本一致连接被拒绝返回码 4用户名或密码错误检查认证配置连接被拒绝返回码 5未授权检查 Broker 的 ACL 配置连接成功但立即断开Client ID 冲突确保每个客户端 Client ID 唯一频繁断线重连Keepalive 设置过短适当增大 keepalive 或优化网络Client ID 冲突这个问题我遇到过好几次。两个客户端用了相同的 Client ID 连接同一个 BrokerBroker 会把先连接的那个踢掉。调试的时候如果发现设备莫名其妙掉线先检查 Client ID 是不是重复了。生产环境建议用设备唯一标识如 MAC 地址、IMEI作为 Client ID。6.2 消息收发异常排查消息发出去了但订阅端收不到排查思路按顺序来先确认订阅端订阅的主题和发布端发布的主题是否完全匹配包括大小写和斜杠。再确认 QoS 等级是否兼容QoS 0 的消息在订阅端离线时不会保存。然后检查 Broker 的 ACL 是否限制了主题的发布或订阅权限。最后看 Broker 的日志通常会有消息路由的记录。消息重复收到大概率是 QoS 1 的重发机制导致的。如果业务不能容忍重复要么升级到 QoS 2要么在应用层做去重比如每条消息带一个唯一 ID接收端记录已处理的 ID重复的直接丢弃。消息顺序错乱在 MQTT 里是可能发生的尤其是 QoS 1 和 QoS 2 的消息在重发时。MQTT 协议不保证跨主题的消息顺序同一主题同一 QoS 的消息在正常情况下是有序的但重发可能打乱顺序。如果业务对顺序敏感需要在消息里带序列号接收端自己排序。6.3 性能优化实战经验Broker 性能优化有几个方向。连接数优化每个 MQTT 连接都会占用 Broker 的文件描述符和内存连接数上万时需要调整系统的文件描述符限制和 Broker 的最大连接数配置。消息吞吐优化减少不必要的 QoS 1 和 QoS 2 消息能降级到 QoS 0 的就降级。主题设计优化避免过多的通配符订阅尤其是#这种全匹配会增加 Broker 的路由计算量。客户端侧的性能优化主要是减少重连风暴。Broker 重启后大量客户端同时重连会造成惊群效应。解决办法是在客户端重连逻辑里加随机退避比如第一次断线后等 1 到 3 秒再重连第二次等 3 到 8 秒依次递增避免所有客户端在同一时刻发起连接。实操心得在客户端重连逻辑里加指数退避加随机抖动能有效缓解 Broker 重启后的连接风暴。具体做法是重连等待时间 基础时间 × 2^重试次数 随机毫秒数设置一个上限比如 60 秒。6.4 安全配置要点生产环境的 MQTT 部署安全配置不能省。最基本的几条禁用匿名连接为每个客户端分配独立的用户名密码启用 TLS 加密防止消息在传输过程中被窃听配置 ACL限制每个客户端只能发布和订阅自己权限范围内的主题。TLS 配置在 Mosquitto 里需要指定证书文件listener 8883 cafile /path/to/ca.crt certfile /path/to/server.crt keyfile /path/to/server.key require_certificate false客户端连接时需要用tls_set()方法加载 CA 证书。如果用了自签名证书客户端需要把 CA 证书文件带上否则会报证书验证失败。ACL 配置可以精确到用户和主题级别user sensor1 topic readwrite sensors/sensor1/# topic read commands/sensor1/# user monitor topic read sensors/#这样 sensor1 只能读写自己的主题monitor 只能读所有传感器数据但不能发布。权限最小化原则在 MQTT 部署里同样适用。7. 与其他协议的对比与选型参考7.1 MQTT vs gRPCgRPC 和 MQTT 经常被放在一起比较但它们的设计目标完全不同。gRPC 基于 HTTP/2主打高性能的远程过程调用适合服务间的同步通信比如微服务架构里服务 A 调用服务 B 的接口。MQTT 主打轻量级的异步消息传递适合设备到云端的通信。选型逻辑很简单如果你的场景是客户端发一个请求服务端返回一个结果用 gRPC。如果是设备持续上报数据多个消费方按需订阅用 MQTT。两者也可以共存比如设备用 MQTT 上报数据后端服务之间用 gRPC 通信。7.2 MQTT 在 ROS2 中的 QoS 实践ROS2 默认的通信中间件是 DDS但 ROS2 也支持通过桥接的方式接入 MQTT。ROS2 的 QoS 配置和 MQTT 的 QoS 概念有相似之处但不等价。ROS2 的 QoS 包括 ReliabilityReliable/Best Effort、DurabilityTransient Local/Volatile、HistoryKeep Last/Keep All等多个维度比 MQTT 的三级 QoS 更细粒度。在 ROS2 和 MQTT 桥接的场景里需要做 QoS 映射。比如 ROS2 的 Reliable Volatile 通常映射到 MQTT 的 QoS 1Best Effort Volatile 映射到 QoS 0。Transient Local 的 Durability 对应 MQTT 的 retain 消息。这个映射不是一对一的需要根据具体业务需求调整。7.3 工业场景中的协议对接工业环境里常见的协议是 OPC UAKepware 这类 OPC Server 能不能对接 MQTT答案是能但通常需要中间件。Kepware 本身支持 MQTT 作为输出通道可以把采集到的 OPC 标签数据转发到 MQTT 主题上。配置方式是在 Kepware 里添加 MQTT Agent设置 Broker 地址和主题映射规则。MCGS 这类组态软件对接 MQTT 通常通过脚本或驱动实现。有些版本的 MCGS 内置了 MQTT 驱动直接配置就行没有内置的可以通过 Lua 脚本或外部程序做协议转换。AEP 平台这类物联网平台通常提供标准的 MQTT 接入接口设备按照平台规定的主题格式和消息格式接入即可。MATLAB 也有 MQTT 支持通过mqtt函数可以创建客户端对象适合做算法验证和数据分析时的快速原型开发。Android 端的 MQTT 开发一般用 Eclipse Paho Android Service 库封装了连接管理和消息收发用起来比较方便。Spring Boot 集成 MQTT 通常用 Eclipse Paho 的 Java 客户端或者 Spring Integration MQTT。Spring Integration 的方式更符合 Spring 的编程模型通过消息通道和适配器配置把 MQTT 消息接入 Spring 的消息流里。RabbitMQ 开启 MQTT 插件后可以同时处理 AMQP 和 MQTT 消息适合已经在用 RabbitMQ 的团队快速接入 MQTT 设备。MQTT 虚拟串口软件这个需求比较特殊通常是为了让原本走串口通信的上位机软件能通过 MQTT 传输数据。实现方式一般是写一个虚拟串口驱动把串口数据转发到 MQTT 主题或者反过来把 MQTT 消息写入虚拟串口。这类工具在工业现场改造中比较常见用来把老设备接入新的物联网平台。选型这件事没有标准答案关键是把业务需求拆清楚通信是同步还是异步、消息可靠性要求多高、设备资源有多紧张、团队对哪个协议更熟悉。把这些想明白了选哪个协议自然就清楚了。MQTT 不是万能的但在设备通信这个领域它确实是最趁手的工具之一。