mqtt 如何知道对方有没有收到消息

原创于 2025-09-06 10:40:40 发布 · 556 阅读

CC 4.0 BY-SA版权

文章标签：

这是一个非常核心且常见的MQTT问题。在MQTT协议中，确认消息是否送达取决于你使用的服务质量等级。

简单来说，MQTT提供了三种不同级别的服务质量（Quality of Service， QoS），它们决定了消息送达的保证程度。

机制：这是一个两步确认流程。
1. 发送者发布一条消息，并等待接收者的确认（PUBACK）。
2. 接收者（对于发布者来说，第一接收者是Broker）收到消息后，必须回复一个PUBACK包。
3. 发送者只有在收到这个PUBACK之后，才认为消息已成功送达。如果在一定时间内没收到PUBACK，发送者会重复发送这条消息，直到收到确认为止。
关键点：
- 发送者可以知道消息已经到达了Broker。
- 因为可能重发，所以接收者可能收到重复的消息，你的订阅端代码需要能处理这种情况（保证幂等性）。
结论：你可以确认Broker已经收到了消息。这是最常用的平衡了可靠性和性能的级别。

机制：这是一个四步握手流程，最可靠但也最慢。它通过两个来回的确认来确保消息既不会丢失也不会重复。
1. 发送者发送消息（PUBLISH）。
2. 接收者收到后回复一个PUBREC（已收到）。
3. 发送者收到PUBREC后，再发送一个PUBREL（发布释放）。
4. 接收者收到PUBREL后，再回复一个PUBCOMP（发布完成），整个流程结束。
关键点：
- 这是最安全、最可靠的方式，保证消息既不丢失也不重复。
- 开销最大，延迟最高。
结论：你可以确认Broker已经收到且只收到一次消息。适用于金融交易等对可靠性要求极高的场景。

上面的QoS 1和QoS 2只能保证消息从发布客户端 成功送达到了Broker。

那么，如何知道消息已经从Broker成功送达到了最终的订阅客户端呢？

这需要另一个机制：** retained message（保留消息）** 和 Last Will and Testament（遗嘱消息） 不直接解决这个问题。要确认“端到端”的送达，需要使用应用层的确认。

常见做法：

发布和订阅确认主题
- 发布者向主题 command/restart 发送一条消息（QoS 1）。
- 订阅者设备执行重启命令。
- 设备重启并重新连接后，立即向另一个主题 status/online 发布一条确认消息（例如：{"deviceid": "abc123", "status": "online"}）。
- 发布者订阅 status/online 主题，当收到来自特定设备的确认消息时，就知道命令已被执行。
使用消息ID进行匹配
- 发布者发送一条消息，其中包含一个唯一的消息ID（如 {“msgId": "uuid123", "cmd": "reset"}）。
- 订阅者收到并处理消息后，向一个确认主题（如 ack）发布一条消息，内容中包含同一个消息ID（如 {“msgId": "uuid123", "status": "success"}）。
- 发布者监听 ack 主题，通过匹配 msgId 就知道哪条原始消息被成功处理了。

QoS级别	能否知道Broker收到？	能否知道订阅者收到？	性能	使用场景
QoS 0	否	否	最高	传感器数据、非关键性日志（丢失一两条没关系）
QoS 1	是	否	中等	最常用。控制命令、重要状态更新（需要知道Broker已接收）
QoS 2	是（且不重复）	否	最低	非常关键的消息，且无法忍受重复（如支付确认）

最佳实践：

对于重要消息，至少使用QoS 1来确保Broker已经收到。
如果必须知道最终订阅客户端是否收到并处理了消息，你需要在自己的应用层协议中实现确认机制（例如使用一个专门的ACK主题）。
大多数客户端库（如Paho）都提供了内置的方法来处理QoS的确认。例如，在Paho Python中，调用publish()会返回一个MQTTMessageInfo对象，其rc属性可以表明消息是否已发送到Broker（对于QoS 0是立即返回，对于QoS 1/2是收到确认后才返回成功）。