聊聊 MQTT：物联网的“普通话”

你有没有想过，智能家居里的设备之间是怎么"聊天"的？比如，温度传感器检测到室温过高，是怎么通知空调自动打开的？又或者，你的手机 APP 是怎么远程控制花园里的喷灌系统的？

这些设备往往来自不同厂商，运行在不同的硬件平台上，使用不同的编程语言开发。让它们高效、可靠地相互通信，并不是一件容易的事。而 MQTT 协议，正是为了解决这类问题而生的。

MQTT 的全称是 Message Queuing Telemetry Transport （消息队列遥测传输协议）。名字听起来很唬人，但它的设计目标其实非常朴素：用最少的带宽和电量，在不可靠的网络环境下，实现设备间的可靠通信。

它诞生于 1999 年，由 IBM 的安迪·斯坦福-克拉克（Andy Stanford-Clark）和阿兰·尼普（Arlen Nipper）共同发明。最初的应用场景是石油管道监控------设备位于沙漠深处，网络带宽极其有限，而且经常断线。是不是很像今天的物联网场景？

2014 年，MQTT 成为了正式的 OASIS 标准，后来又被 ISO/IEC 采纳为国际标准。如今，从 AWS IoT、Azure IoT Hub 到 Home Assistant、开源项目如 EMQX，到处都能看到它的身影。

MQTT 采用了一种被称为 发布/订阅（Publish/Subscribe）的架构，这和我们熟悉的 HTTP "请求/响应" 模式（客户端问、服务器答）有很大不同。

它主要涉及三个角色：

发布者（Publisher）：负责发送消息的设备。每个发布者只需要把消息发到一个"中间人"那里就行，它不需要知道谁会收到这条消息，也不关心有多少人会收到。
订阅者（Subscriber）：负责接收消息的设备。订阅者告诉"中间人"，自己对哪类消息感兴趣，然后当有这类消息到来时，它就会收到通知。
代理（Broker）：这是 MQTT 的核心，也就是那个"中间人"。它负责接收所有发布者的消息，并根据订阅关系，把消息准确地分发给所有订阅者。

发布者和订阅者的角色并不是固定的。同一个设备完全可以既发布消息（比如上报温度），也订阅消息（接收控制指令）。

这种设计带来了一个巨大的好处：解耦。发布者和订阅者完全不需要知道彼此的存在，也不需要同时在线。发布者可以把消息发给 Broker 就转身离开，订阅者也可以等自己上线之后再去 Broker 取消息。这让系统变得非常灵活，扩展起来也特别方便。

Broker 怎么知道要把消息发给谁呢？全靠 Topic。

Topic 是一个用斜杠分隔的字符串，定义了一条消息属于哪个"主题"。例如：

订阅者可以订阅一个精确的 Topic，比如只订阅 home/livingroom/temperature。也可以使用通配符来订阅一批 Topic：

+：单层通配符。订阅 home/+/temperature 会收到 home/bedroom/temperature 和 home/livingroom/temperature，但不会收到 home/livingroom/light/sensor。
#：多层通配符。订阅 home/# 会收到 home/ 下的所有主题，包括 home/bedroom/temperature 和 home/bedroom/light/status。

通过灵活设计 Topic 的层级结构，你可以像设计文件目录一样，清晰地组织成千上万个设备的消息。

物联网网络是出了名的不稳定。Wi-Fi 会断，4G 信号会弱，设备可能会突然掉电。MQTT 通过 QoS（Quality of Service，服务质量） 等级来处理这个问题，确保消息能可靠送达。

QoS 分为三个等级：