MQTT 消息中是否保留了消息顺序？

Question

不知消息发送顺序是否保留。也就是说，当发布者发送一系列消息时，是否保证每个订阅者都收到与发布者发送的相同的序列？对于干净和持久的会话？

Answer 1

可以在规范本身中找到 MQTT 3.1.1 中消息排序功能的摘要 here。

总结：

• 不保证使用不同 QoS 值发布的消息的相对顺序。 （例如，QoS 0 可以取代 QoS 2，因为它涉及单个数据包而不是后者的 4 个数据包）。
• QoS 0 消息将按顺序传递（尽管消息可能会丢失）
• QoS 2 消息将按顺序传送
• QoS 1 允许消息重复 - 有可能在发布的下一条消息的第一个实例之后到达副本。

如果 client/broker 任何时候只允许一条消息在传输中，则可以保证 QoS 1 排序。

Answer 2

when a publisher sends a sequence of messages, is each subscriber guaranteed to receive the same sequence as the publisher had sent it?

这个问题已经得到回答并被广泛接受，但我在 .

中看到以下陈述存在问题

QoS 2 messages will be delivered in order

根据 documentation，提到数据包序列 PUBLISH、PUBREC、PUBREL、PUBCOMP 将按主题维护QOS 2 级留言。但是，订阅者仍然可以按照与发布者发布的顺序不同的顺序接收（可能但很少见）。同样的逻辑也适用于 QOS 1.

让我们看看如何：

1. 代理已为消息 m1 发送 PUBLISH 数据包。

2. 代理已为消息 m2 发送 PUBLISH 数据包。

3. 订阅者已为消息 m1 发送 PUBREC 数据包。

4. 订阅者已为消息 m2 发送 PUBREC 数据包。

5. 消息 m1 的代理已发送 PUBREL 数据包。 但是掉线了

6. 消息 m2 的代理已发送 PUBREL 数据包。

7. 订阅者已为消息 m2 发送 PUBCOMP 数据包。

8. 消息 m1 在代理处的 PUBREL 数据包超时。 Broker 将重试消息 m1.

9. Broker 重新传输消息 m1 的 PUBREL 数据包。

10. 订阅者已为消息 m1 发送 PUBCOMP 数据包。

通过上面的顺序，消息m2有可能首先在接收方被处理。但是，m1 是在 m2 之前发布的。

查看此 了解更多详情。

图片取自u-blox。