MQTT QoS 1消息重发存储位置及客户端持久化作用咨询

一、订阅端断开后重发QoS 1消息存在哪？ #

当订阅端用clean session=false重新连接时，断开期间没收到的QoS 1消息是存在MQTT Broker上的。

• 原理很直接：订阅端用clean session=false连接时，Broker会为它保留会话，里面存着这个订阅端没确认接收的QoS 1/2消息，还有它的订阅关系。只要会话没过期，重连后Broker就会把这些积压的消息推过来。

二、是发布端客户端存这些消息，还是Broker存？ #

这完全是两回事：

• Broker负责存订阅端的未收消息：就是刚才说的，给订阅端保留会话，存它断开期间该收但没收到的QoS 1/2消息，保证重连后能拿到。
• 发布端客户端的持久化，存的是自己发出去但没收到Broker确认的消息：比如用Paho发QoS 1消息，Broker还没回PUBACK，这时候客户端崩了或者断网了，重启后如果用clean session=false连接，客户端就能从持久化存储里把这些没确认的消息找出来，重新发给Broker，确保Broker能收到并转发。

三、Paho客户端持久化到底有啥用？ #

核心就是帮发布端保住消息，确保能成功发给Broker：

• 存住发布端发的QoS 1/2消息，直到收到Broker的确认（QoS1等PUBACK，QoS2等PUBCOMP）。
• 要是发布端意外断连或者崩溃，重启后用clean session=false重连，就能从持久化里恢复没发完的任务，不会丢消息。
• 内存持久化速度快，但客户端重启后数据就没了；文件持久化能跨重启保留消息，适合要求高可靠性的场景。

内容的提问来源于stack exchange，提问作者devesh joshi