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

Question

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

Answer 1

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

总结：

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

如果客户端/经纪人在任何时候只允许单个消息飞行，则可以保证QoS 1排序。

Answer 2

<块引用>

当发布者发送一系列消息时，是否保证每个订阅者收到的序列与发布者发送的序列相同？

此问题已得到解答并被广泛接受，但我发现 accepted answer 中的以下语句存在问题。

<块引用>

QoS 2 消息将按顺序传递

根据documentation，提到数据包的序列PUBLISH、PUBREC、PUBREL、PUBCOMP 将在{{ 1}} 级消息。但是，订阅者仍然可以以与发布者发布的顺序不同的顺序接收（可能但很少见）。同样的逻辑也适用于 QOS 2。

让我们看看如何：

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

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

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

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

5. 消息 m1 的代理已发送 PUBREL 数据包。 但它被丢弃了。

6. 代理已经为消息 m2 发送了 PUBREL 数据包。

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

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

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

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

按照上述顺序，消息m2有可能首先在接收方处理。但是，m1 是在 m2 之前发布的。

有关详细信息，请参阅此 answer。

图片取自u-blox。