MQTT之重复消息（4、重复机制的核心原因详解）

一、底层重复机制的核心原因

1. MQTT QoS 1 的协议设计本质

• "At Least Once"语义：QoS 1 的核心设计目标是确保消息必达，而非避免重复。

• 无状态重传机制：发送方（设备A/Broker）仅通过 Packet ID 识别消息，不检查消息内容是否重复。

• 独立确认机制：设备A→Broker 和 Broker→设备B 是两个独立的 QoS 1 流程，各自的重传互不影响。

2. 网络波动触发的重传场景

flowchart TD
    subgraph 设备A到Broker
    A1[设备A发送PUBLISH PID=100] -->|网络中断| A2[未收到PUBACK]
    A2 --> A3[等待超时后重发Dup=1]
    end

    subgraph Broker到设备B
    B1[Broker转发PUBLISH PID=200] -->|ACK丢失| B2[未收到PUBACK]
    B2 --> B3[Broker重发Dup=1]
    end

---

二、分层的技术原因分解

1. 传输层原因（TCP + MQTT 叠加）

层级	机制	导致重复的影响
TCP层	报文丢失时会自动重传	可能造成 MQTT 报文重复到达 Broker/设备
MQTT层	QoS 1 自带重传机制（Dup=1）	与 TCP 重传叠加，放大重复概率

2. Broker 行为原因

• 消息存储策略：

  // 伪代码：Broker处理PUBLISH的逻辑
  void handlePublish(PublishMessage msg) {
      if (msg.qos == 1) {
          storage.save(msg.pid, msg.payload); // 不检查内容是否已存在
          sendPubAck(msg.pid);
      }
      forwardToSubscribers(msg); // 无条件转发给订阅者
  }

• PID 重新分配：Broker 为每个转发链路分配新 PID，导致：

  • 设备A的原始 PID（如100）与设备B接收的 PID（如200）无关联

  • 无法通过 PID 追溯消息来源

3. 设备端行为原因

• 无应用层去重：默认仅依赖 MQTT 协议层的 PID，而 PID 的作用域仅限于单次传输链路。

• ACK 丢失处理：

  # 设备B的伪代码逻辑
  def on_publish(msg):
      if msg.pid in processed_ids:  # 通常不维护历史PID记录
          return
      process(msg)
      send_puback(msg.pid)  # 可能丢失

---

三、深度场景分析

场景 1：设备A未收到PUBACK

1. 首次发送：

   • 设备A发送 PID=100 的 PUBLISH

   • Broker 存储消息并返回 PUBACK，但 ACK 丢失

2. 重传发生：

   • 设备A超时后重发相同 PID 的 PUBLISH（Dup=1）

   • Broker 必须再次存储（协议要求）

   • 设备B会收到两条内容相同但 Broker-PID 不同的消息

场景 2：设备B未发送PUBACK

1. Broker 首次转发：

   • 使用 PID=200 发送给设备B

   • 设备B处理成功但 PUBACK 丢失

2. Broker 重传：

   • 超时后以相同 PID=200 重发（Dup=1）

   • 设备B无法区分是否是重传（除非维护已处理 PID 列表）

---

四、协议规范中的明确要求

MQTT 5.0 规范 必须 实现以下行为：

1. 对 QoS 1 的 PUBLISH：

   • 接收方（Broker/设备B）必须接受重复的 Packet ID（3.3.1节）

   • 发送方必须存储消息直到收到 PUBACK（4.3.3节）

2. 对 DUP 标志：

   • 重传时必须设置 Dup=1，但仅作为提示（3.3.1节）

   • 接收方不得仅因 Dup=1 就丢弃消息

---

五、解决方案的底层原理

1. 业务层去重（推荐方案）

// 基于业务唯一ID的去重（非MQTT PID）
public void handleMessage(String payload) {
    String bizId = extractBizId(payload); // 如设备A生成的request_id
    if (redis.setNX("dedup:"+bizId, "1", 24, HOURS)) {
        process(payload); // 真实处理
    }
}

为何有效：

• 突破 MQTT PID 的作用域限制

• 直接针对业务数据去重

2. MQTT 5.0 的 Message Expiry

message.setProperties().setMessageExpiryInterval(30); // 30秒过期

底层影响：

• Broker 会在过期后丢弃消息

• 但无法解决短期内的重复问题

---

六、总结：重复的根本矛盾

层级	设计要求	导致重复的必然性
协议层	保证可靠性高于避免重复	QoS 1 必须允许重复
网络层	不可靠传输	重传机制必然存在
应用层	默认无状态处理	不主动去重

最终结论：
        MQTT QoS 1 的重复是协议设计、网络特性和实现机制共同作用的必然结果，必须在应用层通过业务标识实现幂等处理。