MQTT 3.1.1 QoS1消息重发规则及延迟发PUBACK方案可行性咨询

核心疑问解答 #

1. MQTT broker是否会重发订阅方未确认的QoS 1消息？ #

是。这是MQTT 3.1.1协议对QoS 1（至少一次交付）的强制要求：broker向订阅方下发QoS 1级别的PUBLISH报文后，会暂存该报文直到收到对应报文ID的PUBACK确认，未收到确认就会触发重发，和你之前的理解一致。

2. MQTT broker重发未确认消息前的等待时长是多少？ #

MQTT 3.1.1协议未定义统一的重发间隔，该参数完全由broker的具体实现决定，不同broker的默认值差异较大：例如Mosquitto默认重发间隔为5秒，EMQX默认1秒，绝大多数broker都支持用户自定义配置该参数。

3. MQTT broker会无限次尝试重发未确认的消息吗？ #

协议本身没有强制限制重发次数，但所有商用/开源的broker实现都不会做无限重发，通常会通过两个维度限制重发行为：

• 最大重发次数：超过次数后消息要么被丢弃，要么转入死信队列存储
• 消息TTL（生存周期）：超过预设存活时间还未被确认的消息会被直接清理，不再触发重发
  上述两个参数一般都支持用户自行配置。

4. 还有哪些其他触发重发的途径？ #

除了PUBACK超时的常规触发场景外，还有两类常见的重发触发场景：

• 订阅方使用持久会话（Clean Session = 0）断线重连时，broker会将会话中所有未确认的QoS 1/QoS 2消息批量重发
• broker发生节点重启、主备切换等故障恢复动作时，未完成确认的消息也会被触发重发

落地方案合理性评估 #

你提出的「将PUBACK发送时机推迟到消息成功持久化之后，持久化失败则不返回PUBACK，依赖broker自动重发兜底」的方案是行业通用的可靠消费实现方案，完全合理有效。
该方案本质是将MQTT协议层的交付保证和业务层的处理结果做了绑定，彻底避免了「订阅方收到消息立刻返回PUBACK，但后续持久化/业务处理失败导致消息丢失」的漏洞，相当于把QoS 1的至少一次交付能力延伸到了业务处理环节。
落地时需要注意两个配套事项：

1. 必须在业务侧实现消息去重逻辑：QoS 1本身就保证至少交付一次，重发必然会带来重复消息，你需要基于报文ID或者业务唯一标识做判重，避免重复写入持久化存储产生脏数据
2. 需和broker的重发策略适配：提前确认所用broker的最大重发次数、消息TTL配置，如果业务侧持久化故障的恢复时间可能较长，需要适当调大对应参数，避免消息还没来得及处理就被broker清理，也可以搭配死信队列做极端场景的兜底。

内容的提问来源于stack exchange，提问作者Thomas Jäckle