MQTT Part 7 持久会话和消息队列

本文翻译自http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages

未经允许，不得转载

持久会话

当一个客户端连接到MQTT broker时，它需要订阅所有它感兴趣的主题以便从broker接收消息。再重新连接时，已订阅的主题会丢失，而客户端需要重新发起订阅。在没有持久会话时这是一个正常的流程。但是对于资源受限的设备来说，每次重连都需要重新订阅会是较大的负担。所以，持久会话在broker上保存了所有关于此客户端的信息以解决此问题。会话由客户端建立连接时提供的clientId所确定。

哪些信息会被存在会话里呢?

• 即使没有订阅，也会生成会话
• 所有订阅信息
• 所有尚未被客户端确认，且QoS为1和2级别的消息
• 所有因客户端离线而没有收到，且QoS为1和2级别的消息
• 所有客户端已经收到，但尚未确认的QoS为2的消息

这意味着即使客户端离线，所有上述信息也会被broker存储起来，等下次客户端重新连接时继续使用。

怎样启动/关闭持久会话

持久会话可以客户端和broker建立连接时被请求建立。客户端可以通过cleanSession标志来控制broker是否需要存储会话（请见part 3中客户端和broker建立连接部分）。如果cleanSession被置为true那么客户端将不存在持久会话并且在任何情况下连接断开时所有的消息都会被丢弃。当cleanSession被置为false时，持久会话将会被创建，直至客户端再次将cleanSession置为true。如果一个持久会话是可用的，那么消息将会以队列的形式投递给可用的客户端。

客户端如何知道会话是否被存储？

从MQTT 3.1.1开始，borker发送的CONNACK消息包含了当前会话标志，它向客户端表明了当前的会话是否可用。更多详细信息请参见Part 3中的建立连接部分

客户端上的持久会话

同样的在客户端上，每一个MQTT客户端也必须存储一个持久会话。所以当客户端要求服务器存储会话数据时，客户端本身也有责任保留一些信息：

• 所有QoS为1和2的，切尚未被broker确认的消息
• 所有已收到的但尚未被broker确认的QoS为2的消息

最佳实践

你应该在何时使用和清空持久会话？

持久会话

• 客户端必须接收某一主题的所有消息，即使它已经离线。broker需要将消息进行排序，并在客户端连上来时将消息发给它。
• 客户端仅具备有限资源并且broker需要控制订阅内容，当通信中断后需要快速恢复。
• 客户端需要在重连后继续发布QoS 1和2级别的消息。

清空会话

• 客户端只发布而不订阅主题消息，QoS为1和2级别的消息在重连后也无需重发。在这种情况下它不需要在broker上存储任何会话信息。
• 客户端在离线时不需要接收消息。

消息应该被储存在broker上多久？

一个经常被问到的问题是会话应该被储存在broker上多久。一个简单的答案是应该存储到客户端重新上线时。但是如果客户端很久都不再上线了呢？毕竟操作系统的内存是有限的。对此没有一个确定的解决方案。这完全取决于使用场景。在HiveMQ中，我们提供了一个方法来操纵消息队列并可以清空它们。