MQTT 学习笔记#

📌 打个比方：MQTT 像一个广播电台系统。Publisher（发布者）是电台节目制作人，Broker（代理）是发射塔，Subscriber（订阅者）是听众。制作人不需要知道谁在听，听众也不需要知道谁在播——发射塔负责把节目推给所有订阅了该频道的听众。这就是发布/订阅解耦。

📌 为什么 IoT 首选 MQTT 而不是 HTTP？HTTP 是请求-响应模式——传感器要上报数据得主动发请求，服务器不能主动推送。MQTT 是发布-订阅模式——设备只需建立一次连接，之后双向实时推送。而且 MQTT 头部最小仅 2 字节，HTTP 头部动辄几百字节——在 2G 网络下传 1KB 数据，MQTT 的协议开销可以忽略，HTTP 的头部可能比数据本身还大。

📌 为什么需要 Broker 中间人？如果设备和后端直接连接，每台设备都要知道后端 IP、处理网络断连重试、维护多后端负载均衡。Broker 把这些复杂性集中处理——设备只需连 Broker，后端也只需连 Broker，Broker 负责路由。这是经典的中介者模式：把 N×M 的网状连接简化为 N+M 的星型连接。

📌 为什么用变长编码？IoT 设备消息通常很小（几十字节到几 KB），1 字节就能表示 0-127 的长度。如果用固定 4 字节表示长度，每条消息多 3 字节开销——对于每秒发一条温度数据的传感器，一天多 260KB，在 2G 网络下不可忽略。变长编码让小消息用 1 字节，大消息用最多 4 字节，按需付费。

📌 QoS 1 为什么会重复？发送方发 PUBLISH，接收方收到并回 PUBACK。但 PUBACK 在网络中丢了——发送方超时后重发 PUBLISH（DUP=1），接收方再次收到同一条消息。协议层面无法消除这种重复，因为接收方无法区分"新消息"和"PUBACK 丢失后的重发"。去重是应用层的责任。

📌 QoS 2 为什么需要四步而不是两步？两步（PUBLISH + PUBACK）就是 QoS 1，会重复。QoS 2 的思路是：先确认"我收到了"（PUBREC），再确认"你可以处理了"（PUBREL），最后确认"我处理完了"（PUBCOMP）。接收方在收到 PUBREL 之前不投递消息——如果 PUBLISH 重复到达，接收方发现 PacketID 已存在，只回 PUBREC 不重复投递。用两轮确认换取恰好一次。

📌 QoS 越高越好吗？不是。QoS 2 的四步握手意味着每条消息 4 次网络往返——在 200ms 延迟的 2G 网络下，一条消息要 800ms。QoS 0 只需 1 次发送。按业务需求选最低够用的 QoS，不要无脑用 QoS 2。

📌 为什么 Topic 用层级而不是扁平名？层级结构天然支持过滤和分组。订阅 home/+/temperature 一次获取所有房间的温度，订阅 home/# 获取家里所有数据。扁平命名（如 home_livingroom_temperature）做不到这种模式匹配。层级 = 结构化 = 可聚合。

📌 Topic 设为什么会影响性能吗？会。Broker 对 Topic 做树形索引匹配——层级越深，匹配开销越大。但这个开销在万级 Topic 以下可以忽略。真正影响性能的是订阅数量和消息频率，不是 Topic 层级深度。设计 Topic 优先考虑可读性和可聚合性，不要为了性能牺牲结构。

📌 为什么需要心跳？TCP 连接断开有两种：正常关闭（FIN）和异常断开（断电、信号丢失）。异常断开时 TCP 不会发送 FIN——对端不知道连接已断，直到尝试写入时收到 RST。心跳机制让双方在空闲时也能检测连接状态，及时发现异常断开并触发遗嘱消息。心跳 = 主动探测 vs 被动等待超时。

📌 什么时候用 Clean Session = false？设备可能频繁断网（如移动设备进隧道），但离线期间的消息不能丢（如控制指令）。设 false 后，Broker 为该客户端存储离线消息，重连后投递。代价是 Broker 要持久化存储——如果 100 万设备都设 false，每个积压 100 条消息，Broker 要存 1 亿条。按需使用，设合理的过期时间。

📌 为什么取最小值？QoS 是发送方的承诺——QoS 2 的发布者保证"恰好一次"，但 QoS 0 的订阅者没做接收确认机制，无法保证。取 min 确保不"虚假承诺"：订阅者没声明能处理 QoS 2，就不能强制给它 QoS 2 的保证。QoS 是双方协商的最低公约数。

📌 Retained 消息解决什么问题？新设备上线后需要知道当前配置（如采样间隔、阈值），但配置消息可能早就发过了。没有 Retained，新设备订阅后只能等下一次配置变更才能收到——可能等几小时。有 Retained，Broker 立即把最后一次配置推给新设备。Retained = Topic 的"最后状态快照"。

📌 什么时候不该用 Retained？高频变化的数据（如温度每秒更新）——每次都设 Retained 会让 Broker 不断覆写存储，浪费资源。Retained 适合低频、状态型数据（配置、开关状态、设备型号）。

📌 为什么正常 DISCONNECT 不触发遗嘱？正常断开是客户端主动告知"我要走了"，不需要遗嘱——客户端自己可以发一条"offline"消息。遗嘱是为不可控的异常断开设计的——设备断电、信号丢失时无法主动发消息，Broker 代发。如果正常断开也触发遗嘱，客户端就没法区分"主动离线"和"异常掉线"了。

📌 Retained + Will 的经典组合：设备上线时发 status=online（retained），遗嘱设 status=offline（retained）。任何订阅者随时能读到设备当前在线状态——在线时是 online，异常掉线后 Broker 自动改为 offline。这是 IoT 设备状态管理的标准模式。

📌 MQTT 5.0 的 Reason Code 为什么重要？MQTT 3.1.1 连接失败只告诉你"失败"——是密码错？协议版本不对？还是 Broker 满了？客户端只能猜。MQTT 5.0 给出具体原因码，客户端可以智能重试——密码错就不重试，Broker 满了可以等一会儿再试。从"哑巴"到"会说话"。

📌 Topic Alias 省多少？如果 Topic 是 factory/line1/machine3/sensor/temperature（38 字节），每条消息都要带。如果 Payload 只有 25.5（4 字节），Topic 占了 90% 的包大小。用 Alias 后后续消息 Topic 字段为 0 字节，只传一个 2 字节的 Alias ID。高频小消息场景下省带宽效果显著。

📌 Shared Subscription 解决什么问题？如果 1000 个设备发消息到 device/event，后端 1 个订阅者处理不过来。加更多订阅者——但普通订阅下每个订阅者都收到全量消息，1000 条消息变成 1000×N 条。Shared Subscription 让 N 个订阅者分摊消息——每人处理 1000/N 条。这是 MQTT 版的消费者组模式，类似 Kafka 的 Consumer Group。

📌 持久化 vs 内存模式怎么选？如果设备都是 Clean Session=true（不需要离线消息），内存模式即可——Broker 重启后设备重连，全新会话。如果有设备用 Clean Session=false（需要离线消息），必须持久化——否则 Broker 重启后离线消息全丢。持久化有写入开销，按业务需求决定。

📌 为什么 MQTT 安全特别重要？MQTT Broker 常暴露在公网（设备要远程连接）。如果无认证——任何人都能订阅你的设备数据或发控制指令。最低限度也要用户名/密码 + TLS。生产环境推荐客户端证书——每台设备一个证书，即使密码泄露没有证书也连不上。

📌 为什么不用 HTTP 的安全方案？MQTT 是长连接，不能用 HTTP 的 Bearer Token 模式（每次请求带 Token）。MQTT 只在 CONNECT 时认证一次，之后整个连接生命周期不再认证。所以认证信息要"够重"——证书比密码更难窃取。

📌 Mosquitto vs EMQX 怎么选？Mosquitto 是 C 写的单线程——轻量但上限在几万连接。EMQX 是 Erlang 写的——天生支持高并发，单节点百万连接，集群千万级。边缘网关用 Mosquitto，云端平台用 EMQX。如果你不确定，先用 Mosquitto——简单稳定，等规模上来再迁 EMQX。

📌 嵌入式设备选什么库？内存极小（< 64KB RAM）用 Mbed MQTT 或 esp-mqtt（ESP32）。有操作系统（Linux）用 Paho MQTT C。资源够用（> 1MB RAM）可以用 Paho MQTT C++ 或 mosquitto client。选库的核心指标是RAM 占用和代码体积，不是功能多少。

📌 为什么需要边缘网关？工厂里 200 个传感器如果各自连云端 Broker——200 条公网 TLS 连接，每条握手 10KB，200 个证书管理。用边缘网关：200 个传感器连本地 Mosquitto（无 TLS，毫秒延迟），Mosquitto 用 1 条 TLS 连接桥接到云端。聚合连接、降低延迟、简化证书管理。