MQTT 踩坑指南

MQTT（Message Queuing Telemetry Transport 消息队列遥测传输协议）是一种基于发布/订阅（publish/subscribe）模式的 “轻量级” 通讯协议，该协议构建于 TCP/IP 协议上，最早由 IBM 在 1999 年发布。目前由 OASIS 维护 MQTT 标准

OASIS 这个组织维护的标准大部分人应该都没听说过

不过 AMQP — Advanced Message Queuing Protocol 大概不用多说。。。大名鼎鼎的 RabbitMQ 就是实现的这个协议

MQTT 最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用。

实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。

MQTT传输的消息分为：主题（Topic）和负载（payload）两部分

由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

精简，不添加可有可无的功能；
发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递；
允许用户动态创建主题，零运维成本；
把传输量降到最低以提高传输效率；
把低带宽、高延迟、不稳定的网络等因素考虑在内；
支持连续的会话控制；
理解客户端计算能力可能很低；
提供服务质量管理；
假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

ClientID

这个必须是唯一的。如果没有设置就会随机生成一个

如果有 ClientID 相同的就会把之前的挤掉

Last Will （遗愿消息）

MQTT 客户端向服务器端 CONNECT 请求时，可以设置是否发送遗愿消息(Will Message)标志，和遗愿消息主题(Topic)与内容(Payload)。

注：

遗愿消息只有 CONNECT 才能设置

MQTT 客户端异常下线时(客户端断开前未向服务器发送 DISCONNECT 消息)，MQTT 消息服务器会发布遗愿消息。

如果你想区分连接状态（网络错误和主动关闭）的话应该自定义一个状态的 topic 配合 Last Will 来使用

Retain（驻留）

MQTT 客户端向服务器发布(PUBLISH)消息时，可以设置驻留消息(Retained Message)标志。驻留消息(Retained Message)会驻留在消息服务器，后来的订阅者订阅主题时仍可以接收该消息。

同一 Topic 下的 Retain 消息有且只能有一条，后来的驻留消息会取代前一条驻留消息

QoS （质量控制）

qos	描述
`0`	无任何保证
`1`	一定会到达
`2`	一定会到达并且只会到达一次

MQTT 发布消息 QoS 保证不是全部的，是客户端与 Broker 之间的

QOS 是针对与和 Broker 通信，因此 publish 了一条消息并不能保证 subscriber 一定会收到，比如：发消息时订阅还没有完成

mqttv5 新特性：请求响应可以解决这个问题

不过 mqttv5 这也有问题。。我有要是多个订阅者那（按照你业务具体需求来实现吧，返回个 ${ClientID} ACK 之类的）

Topic (主题：消息路由）

主题 (Topic) 通过 / 分割层级，支持 +, # 通配符:

/a 和 a 是两个完全不同的 topic

+: 表示通配一个层级，例如 a/+，匹配 a/x, a/y

#: 表示通配多个层级，例如 a/#，匹配 a/x, a/b/c/d

可以这样写：

chat/room/1

chat/#

sensor/10/temperature

sensor/+/temperature

注:

订阅者可以订阅含通配符主题，但发布者不允许向含通配符主题发布消息。

mqtt 5 vs mqtt 3.1.1

目前有这两个主要的版本。。mqttv5 的改变巨大

网络波动引起的丢消息问题

mqttv3.1.1 CleanSession

网络波动引起的 Subscribe 状态的丢失

RabbitMQ 收到消息回执（Message acknowledgment）

这点和 RabbitMQ 不同（抱歉，我没有实际使用过 RabbitMQ。如果这个地方说错了，请务必指出）

Reconnect 之后虽然恢复。但 Disconnect 到 Reconnect 之间的信息会丢失

用这个选项是可以解决的 CleanSession 的默认设置是开启的，要关掉这个

还应该把检测掉线延时设置大一点，这样对抗网络波动的能力就更好些

不过这里还有其他问题。。。如果长时间没有恢复（这个看各 broker 是如何实现的）不过 mqttv5 加入了session-expiry-interval 这个地方更完善了

eclipse Paho 项目

pāho (verb) to broadcast, make widely known, announce, disseminate, transmit (via the Maori dictionary)

paho 是毛利语中的广播的意思

这个项目里有几乎所有语言的 mqtt 库的实现（有钱真好）

Broker

Eclipse Mosquitto

可以把这个当作标准工具来开发，测试，和使用

Mosquitto 提个了非常好用的命令行工具可以用来开发调试

mosquitto_sub
mosquitto_pub
mosquitto_rr

直接用

# 开启起一个 mqtt broker，默认端口为 1883
mosquitto

# 订阅一个名为 test 的 topic
mosquitto_sub -L mqtt://localhost:1883/test

# 推送一条内容为 `233` 的消息到 test
mosquitto_pub -L mqtt://localhost:1883/test -m "233"

# 也可以这样订阅 topic 再推送消息
mosquitto_rr -L mqtt://localhost:1883/test -e test -m "233"