3.1 MQTT登场与发布订阅模型
3.1 MQTT 登场与发布订阅模型
本节摘要：介绍 MQTT 的来历、定位与最核心的发布订阅模型——为何 Broker 居中能让发布者和订阅者彻底解耦，以及 MQTT 5.0 相对 3.1.1 在语义上的主要变化。承接 2.3 应用层概览，通往 3.2 的报文解剖。
MQTT 诞生于上世纪九十年代末，本是为了"用一根又窄又不可靠的卫星链路把石油管道的传感器数据传回总部"，如今却成为物联网发布订阅的事实标准。它的关键词可以浓缩成一组：轻量、发布订阅、主题路由、可断线续传。本节先把最要紧的"发布订阅模型"讲透，再看版本演进。
为什么是"发布订阅"而不是"你问我答"
如果让每个传感器都和每个关心者建立点对点连接，设备一多就变成蜘蛛网：每增加一个关心者，传感器就要多维持一条链路。发布订阅把这个困局一次解掉——所有设备只和一台 Broker 交往，数据按"主题"登记，谁想看某个主题就订阅它。发布者发一条消息到主题，Broker 负责把副本推给所有订阅者。发布者完全不需要知道谁在听，订阅者也不关心消息从哪来。
这套拓扑的核心价值是解耦：增加设备、增加订阅者，都是"多挂一条线"的事，不会让其它节点受牵连。
Broker 的分内事
Broker 是这套模型的枢纽，它至少承担四件日常事务：建立连接会话、管理主题订阅表、按主题路由转发、保证 QoS 语义。优秀 Broker（常见名如 Mosquitto、EMQX、HiveMQ）还会附加认证 ACL、桥接与集群。设备端则简化到只剩"连接的客户端"，可发可收可订阅，智商集中于 Broker。
角色与一次完整的通信
我们把角色和一次通信对齐，三句话就走完全程：
- 设备（发布者）持着主题
office/sensor_01/temp发一条 PUBLISH，载荷是温度读数。 - Broker 查订阅表，找到所有订阅了该主题（或其通配上层）的客户端。
- Broker 给每个匹配订阅者各自投递一份副本；投递的可靠性由本次 QoS 决定。
# 一段概念化的订阅-路由示意（非实际语法） subscribe office/sensor_01/temp publish office/sensor_01/temp = { "value": 25.6, "unit": "celsius" } # Broker 内部按 主题->订阅者 表 匹配并多路投递 route_by_topic: office/sensor_01/temp -> [看板A, 告警服务, 环控联动]
版本演进：从 3.1.1 到 5.0
MQTT 3.1.1 是各云平台沿用最广的基线；MQTT 5.0 是自 2019 年后的增强，主要变化集中在更能表达交互语义：返回原因码细分、消息与会话语义过期、共享订阅（负载均衡）、主题别名、用户属性（便于打标与追踪）。选型时不必盲目追新——设备端若只做遥测，3.1.1 已够；若你要一台 Broker 同时给多方做精细授权、做消息审计，5.0 的会话与属性能力更趁手。
💡 关键直觉：MQTT 从来不是"最长的绳子"而是"最灵活的撮合板"——很多团队选 MQTT 不是因为它吞吐最高，而是因为它用主题把设备、告警、看板、App 一网打尽还互不粘连。
主题如何避免"无休止发帖"：保留消息的意义
先插一句常见的"发帖三不限"困惑：设备 A 每分钟往主题发一条温度，可后来的订阅者往往希望一进来就能看到最新值，而不是干等下一次上报。MQTT 用**保留消息（Retain）**解决这个问题：发布者把某条消息标上保留位，Broker 会记下该主题的"最近一条保留值"，任何新订阅者连上时都会立刻收到这一份"存档快照"。它把"发一条实时消息"和"供新订阅者补看"两个诉求一次满足，是老牌发布订阅里最容易遗忘却最实用的一档。
保留位与遗嘱、会话共同构成 MQTT 对"介入状态"的三重表达：保留管"主题现状"、遗嘱管"设备断线该说的遗言"、会话管"离线期间是否补发"。三者在 3.4 里都会正式拆解，这里先给你一张预览图，让"解耦"不再只是抽象口号。
一个常见的错误直觉：发布订阅 == 消息队列？
把 MQTT 当成消息队列（Kafka/RabbitMQ）是不少初学者的常见误解。两者根本差别在于消费是否竞争：消息队列一般把一条消息只交给一个消费者（任务分派、点对点）；MQTT 的发布订阅则默认把一份消息广播给所有匹配订阅者——同一份温度，要看板的拿一份、要告警的拿一份、要联动环控的也拿一份。想用 MQTT 做"任务分发、一轮只有一个人干"，就得靠 5.0 的共享订阅或自建领取逻辑，否则会出现多份重复执行。分清这两套心智模型，才不会在设计时把路由语义用错。
怎样才算"跑通"一次发布订阅
纸上谈兵不如落地验证。一个非常基础的冒烟路径是：订阅端先订阅通配主题，发布端再发一条消息，订阅端能收到即算通。以 mosquitto 客户端为例，一次最小验证是这样：
# 终端1：订阅通配主题, 阻塞等待 mosquitto_sub -h localhost -t 'campus/#' -v # 终端2：发布一条到三层主题 mosquitto_pub -h localhost -t campus/building_a/floor1/temp \ -m '{"value":25.6,"unit":"celsius"}' # 终端1 应打印: # campus/building_a/floor1/temp {"value":25.6,"unit":"celsius"}
这条命令能跑通，说明 Broker 安装正常、TCP 1883 通、发布订阅路由正确，为后续的 QoS 与保留消息验证打好地基。
本节要点回顾
- 要点一：MQTT 起于 1999 年石油管道遥测，以轻量可靠为设计原点。
- 要点二：发布订阅 + 居中 Broker 让发布者与订阅者彻底解耦。
- 要点三：Broker 主责是连接会话、订阅管理、路由转发、保障 QoS。
- 要点四：MQTT 5.0 带来原因码、主题别名、共享订阅等增强，按需选择。
- 要点五：选 MQTT 的本质是看重"主题撮合 + 多方解耦"的组织能力。
下一节钻进报文，看一条 MQTT 消息到底由哪几段组成、主题树和通配符怎么用。