一句话定义：MQTT（Message Queuing Telemetry Transport）是一种建立在 TCP 之上的轻量级发布/订阅协议，专为带宽小、网络不稳、设备算力有限的场景设计。名字里带“Message Queuing”，但它并不是消息队列。
三个角色
发布者（publisher）、订阅者（subscriber），以及中间的 broker（代理）。发布者不直接找订阅者，而是给消息打上一个“主题”（topic，如 factory/line3/temp）发给 broker；订阅者事先告诉 broker 自己关心哪些主题，还能用通配符 factory/+/temp 一次订阅多条产线。broker 只做一件事：按主题把消息投给关心的订阅者。
打个比方，它更像小区的公告栏，而不是快递柜：写公告的人贴到对应栏目，谁关心谁自己去看；贴的人不知道谁在看，看的人也不知道谁在贴——这就是解耦。公告栏管理员不替你保管三个月的旧公告，也不保证一条公告只有一个人读到。
QoS 是“投递努力程度”，不是“业务只消费一次”
QoS 0：最多一次，发出去就不管，可能丢。QoS 1：至少一次，收到要回执，没回执就重发，可能重复。QoS 2：恰好一次，通过多步握手在协议层面做到不重不漏。
关键在于：QoS 2 的“恰好一次”只覆盖客户端与 broker 之间的这一段链路。如果订阅端先执行业务再回执，中途进程崩溃重启；如果存在桥接（bridge）或多级 broker；如果消息在应用层又转了一手——重复照样会发生。所以只要涉及钱、库存、工单这类有副作用的操作，业务侧必须自己做幂等，比如用消息 ID 或业务主键去重。把 QoS 当“防重复开关”用，是这类系统最常见的线上事故来源之一。
和消息队列、HTTP 的区别
| 维度 | MQTT | 消息队列（Kafka、RabbitMQ 等） | HTTP 请求 |
|---|---|---|---|
| 通信模型 | 发布/订阅，按主题过滤 | 队列/日志，消费组竞争消费 | 请求—响应 |
| 连接方式 | 长连接 + 心跳 | 长连接 | 多为短连接 |
| 报文开销 | 极小，适合弱网低功耗 | 较大 | 头部开销大 |
| 历史消息 | broker 一般不留 | 可长期堆积、回放 | 无 |
| 典型场景 | 海量设备上下行指令 | 服务间解耦、数据管道 | 前后端接口 |
对从业者的意义
物联网、车联网、移动推送、工业设备监控是它的主场。放到 AI 项目里，边缘推理盒子用 MQTT 上报设备状态和推理结果，云端用 MQTT 下发模型更新通知、阈值调整指令，都是典型用法。但别拿它当数据湖：它不擅长长期堆积和回放，训练数据该落到消息队列或对象存储。常见做法是两者组合——MQTT 管设备侧最后一段链路，消息队列管后端数据管道。
具体实现细节和各 broker 的能力边界，以官方文档为准。