MQTT Broker在QoS1万级订阅场景下异常重启后的消息处理问题

MQTT Broker 断电后QoS 1消息推送处理方案 #

默认前提：所有订阅者使用持久会话（Clean Session=0），如果是临时会话，断电后会话销毁则不需要再给离线的临时会话订阅者推送。

重启后推送任务处理逻辑 #

结合你给出的Broker处理流程，按三类订阅者分别处理：

• 已完成推送的1000个订阅者：Broker已经执行了步骤3.4删除了对应的消息副本，无未完成的QoS 1交付记录，不需要再处理。
• 处于等待PUBACK状态的4000个订阅者：Broker持久化存储中还保留了步骤3.1存储的对应消息副本，属于未完成的QoS 1交互，需要恢复后继续处理。
• 未启动推送的5000个订阅者：因为步骤1存储的原消息还未删除（全量订阅者都完成推送才会执行步骤4删除原消息），所以需要从头走单订阅者的推送流程。

DUP flag 设置规则 #

DUP flag的作用是标记该报文是之前发送过的重发报文，严格遵循MQTT规范设置即可：

• 给4000个等待PUBACK的订阅者重发消息时，DUP flag设为1
• 给5000个首次推送的订阅者发消息时，DUP flag设为0

已完成推送的1000个订阅者是否需要重推 #

不需要。
QoS 1的核心要求是至少一次交付，这1000个订阅者已经返回了PUBACK，Broker也删除了对应的交付记录，已经完成了交付约定，重复推送反而会造成不必要的资源浪费。

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