JMeter模拟MQTT推送成功但接收不到？

Question

使用JMeter通过MQTT插件模拟消息推送时，常出现“发送成功但接收端收不到消息”的问题。常见原因之一是JMeter仅模拟了连接与发布动作，但未正确订阅主题或未保持长连接，导致消息虽发送成功（QoS 0确认），却因网络中断或会话立即断开而未被Broker持久化或转发。此外，客户端ID重复、遗嘱消息设置不当、或未等待订阅确认即发布，也会导致消息丢失。需检查QoS等级、Clean Session标志及是否启用持久化会话。

Answer 1

使用JMeter通过MQTT插件模拟消息推送时“发送成功但接收端收不到消息”的深度解析

1. 问题背景与现象描述

在物联网（IoT）系统性能测试中，Apache JMeter常借助第三方MQTT插件（如JMeter-MQTT-Plugin）模拟海量设备向MQTT Broker推送消息。然而，开发者常遇到一种典型问题：JMeter控制台显示“Publish Success”，但订阅端（如客户端、服务端监听程序）却未接收到任何数据。

该问题具有较强的隐蔽性，表面看是网络或Broker故障，实则多源于JMeter测试脚本配置不当或对MQTT协议机制理解不深。

2. 常见原因分类分析

• 连接未保持长连接：JMeter默认在发布后立即断开连接，导致QoS 0消息虽被Broker接收，但若网络抖动或Broker处理延迟，消息可能丢失。
• 未正确订阅主题：测试仅包含“发布”Sampler，缺少“订阅”Sampler，无法验证消息是否被正确路由。
• 客户端ID重复：多个线程使用相同Client ID连接，触发Broker踢出旧会话，造成消息中断。
• Clean Session 设置错误：设置为true时，会话结束后所有订阅和未确认消息将被清除。
• QoS等级不匹配：发布端使用QoS 0，而订阅端期望QoS 1以上保障，导致可靠性下降。
• 遗嘱消息干扰：遗嘱消息（Will Message）设置不当，在异常断开时触发误报。
• 未等待SUBACK确认即发布：订阅请求发出后未等待Broker返回SUBACK，导致消息发布时订阅尚未生效。

3. 深度技术剖析：MQTT会话生命周期与JMeter行为对比

阶段	标准MQTT客户端行为	JMeter默认行为	潜在风险
连接建立	发送CONNECT包，携带Client ID、Clean Session等	可配置，但易忽略动态Client ID生成	Client ID冲突
订阅主题	发送SUBSCRIBE，等待SUBACK	常被省略或异步执行	发布时订阅未生效
消息发布	在有效会话中按QoS发送PUBLISH	可能在连接后立即发布并断开	消息未持久化
连接维持	保持TCP连接，响应PINGREQ	多数插件不支持心跳维持	会话过早关闭
断开连接	发送DISCONNECT或自然断开	通常强制关闭Socket	触发遗嘱消息

4. 核心参数检查清单

1. Client ID：确保每个线程使用唯一ID，可通过${__threadNum}或UUID函数生成。
2. Clean Session：若需消息重传或离线消息，应设为false，并配合持久化会话。
3. QoS等级：建议至少使用QoS 1以确保至少一次送达；QoS 0无确认机制，易丢包。
4. Keep Alive Interval：设置合理值（如60秒），避免连接被Broker超时断开。
5. Will Message：测试环境下建议禁用，防止误触发“设备离线”事件。
6. Connection Timeout：增加至10秒以上，适应高延迟网络环境。
7. Reconnect on Failure：启用自动重连机制提升稳定性。
8. Topic Name：确认大小写、斜杠格式与订阅端完全一致。
9. Broker地址与端口：验证是否使用正确的协议（tcp:// vs ssl://）及端口（1883 vs 8883）。
10. 认证信息：若启用用户名/密码，需在连接配置中正确填写。

5. 解决方案设计：构建可靠的JMeter MQTT测试流程

// 示例：JMeter Thread Group 中的逻辑结构
Setup Thread Group
├── MQTT Connect (Clean Session=false, QoS=1)
├── MQTT Subscribe (Topic: sensor/data/${__threadNum}, Wait for SUBACK)
├── Regular Thread Group
│   └── Loop Controller
│       ├── MQTT Publish (Payload: {"temp": ${__Random(20,30)}})
│       └── Timer (e.g., 1s delay)
Teardown Thread Group
└── MQTT Disconnect (Graceful shutdown)
    

6. 流程图：正确的JMeter MQTT测试执行序列

graph TD A[启动线程] --> B[生成唯一Client ID] B --> C[建立MQTT连接
CleanSession=false] C --> D[发送SUBSCRIBE请求] D --> E{等待SUBACK?} E -->|是| F[确认订阅成功] E -->|否| G[直接发布——风险操作] F --> H[循环发布消息] H --> I[保持连接持续N秒] I --> J[发送DISCONNECT] J --> K[结束线程]

7. 高级调优建议

对于具备5年以上经验的工程师，可进一步优化以下方面：

• 分布式压测部署：使用JMeter集群模式模拟万台设备，避免单机资源瓶颈。
• 结合Wireshark抓包分析：验证PUBLISH包是否真正到达Broker，排除插件层假成功。
• Broker日志审计：检查Mosquitto或EMQX日志中的DROP、DENY记录，定位权限或限流问题。
• 引入MQTT.fx或MQTT Explorer作为独立订阅验证工具，脱离JMeter验证消息可达性。
• 自定义JSR223 Sampler编写Groovy脚本，实现更精细的连接状态监控与重试逻辑。
• 利用InfluxDB + Grafana实时监控QoS成功率与端到端延迟，构建完整可观测体系。