文章图片
文章图片
亿佰特串口服务器、CAN-bus转以太网、以太网边缘采集IO网关等系列产品拥有MQTT工作模式 ， 在此工作模式下 ， 可以选择使用阿里云等平台进行相关测试与通信 。
MQTT（Message Queuing Telemetry Transport）是一种轻量级的发布/订阅消息传输协议 ， 广泛应用于物联网领域 。 其核心特性之一是QoS（Quality of Service ， 服务质量） ， 通过定义消息传递的可靠性级别 ， 适应不同的网络环境和业务需求 。 本文将深入解析MQTT的QoS三级服务等级 ， 并结合实际场景和“踩坑”经历举例说明其应用场景和特点 。
一、QoS的概念及分类MQTT协议的QoS（服务质量）其实就是消息传递的可靠性等级 ， 分三个级别 ， 对应不同的“靠谱程度” 。
1. QoS 0（最多传一次）
? 本质：发出去就不管了 ， 不确认也不重传 。
? 适合场景：比如监控办公室温度 ， 偶尔丢几条数据没关系 ， 反正不影响整体趋势 。
2. QoS 1（至少传一次）
? 本质：发完会等对方回个“收到” ， 没回就一直重发 ， 但可能会重复 。
? 适合场景：比如远程控制家里空调关机 ， 怕指令没传到 ， 但重复关一次也没啥问题 。
3. QoS 2（必须传一次且只传一次）
? 本质：玩命保证消息不丢不重 ， 但流程复杂 ， 传输时间长 。
【MQTT QoS服务质量及其应用解析】? 适合场景：比如银行转账 ， 必须确保指令绝对准确 ， 不能多扣钱也不能漏掉 。
二、QoS实际案例1. QoS 0：能省事就省事
? 场景举例：做工厂设备监控系统 ， 传感器每秒上传一次数据 。
? 踩坑经历：一开始用QoS 1 ， 结果发现数据量太大 ， 服务器扛不住 。 后来改用QoS 0 ， 虽然偶尔丢数据 ， 但分析趋势时影响不大 ， 反而系统更稳定了 。
? 经验总结：网络环境好+数据允许少量丢失=选QoS 0 。
2. QoS 1：相对可靠
? 场景举例：客户要做智能门锁远程解锁功能 。
? 踩坑经历：用QoS 1后发现 ， 偶尔因为网络延迟 ， 门锁会收到重复的“开锁”指令 ， 会导致用户反馈“锁老是自己开” 。 可在业务层加了个去重逻辑 ， 比如30秒内重复指令直接忽略 。
? 经验总结：控制类指令选QoS 1 ， 但业务层必须处理重复问题 。
3. QoS 2：绝对可靠但代价高
? 场景举例：医疗设备上传患者生命体征数据到云端 。
? 踩坑经历：因为用QoS 1 ， 某次网络波动导致数据丢失 ， 差点耽误诊断 。 后面硬着头皮改成QoS 2 ， 传输速度慢了点 ， 但数据绝对不丢不重 。
? 经验总结：医疗/金融这种敏感场景 ， 必须用QoS 2 ， 哪怕牺牲性能 。
三、怎么选QoS等级？1. 先看网络环境：
? 网络稳定（比如局域网）→QoS 1足够 。
? 网络差（比如移动网络）→QoS 2更安心 。
2. 再看业务需求：
? 数据趋势分析→QoS 0 。
? 控制类指令→QoS 1 。
? 金融/医疗等高风险场景→QoS 2 。
3. 需要权衡资源：
? QoS 2虽然可靠 ， 但消息要存状态、多握手 ， 对设备内存和CPU要求高 。 如果设备是低端单片机 ， 别硬上QoS 2 。
四、常见误区和避坑指南1. 误区1：QoS等级越高越好
真相：QoS 2的开销是QoS 0的5倍以上！比如我们做过测试 ， 1000条消息用QoS 2比QoS 0多耗电30% 。
2. 误区2：QoS 1永远不会丢消息
真相：如果发送方发完消息就断网了 ， PUBACK可能收不到 ， 这时候消息其实丢了 。 QoS 1只能保证“至少一次” ， 但极端情况下还是可能失败 。
3. 误区3：业务层不用处理重复
真相：QoS 1的重复消息必须自己处理！比如我们之前做智能电表抄表 ， 重复指令导致电量记录出错 ， 后来加了个“唯一ID+缓存校验”才解决 。
五、总结
新手建议：先从QoS 1练手 ， 熟悉协议流程后再尝试QoS 2 。
调试技巧：用Wireshark抓包看看QoS握手过程 ， 能快速定位问题 。
性能优化：QoS 2的消息ID别用UUID ， 用递增的整数 ， 省内存 。
推荐阅读
- Qt/C++编写的mqtt调试助手使用说明
- 物联网开发者必读：从HTTP到MQTT，八大协议全解码！
- 搭建EMQX MQTT服务器并接入Home Assistant和.NET程序
- iqos危害,iqos危害
- iqos和真烟哪个危害大,单论危害性，电子烟和真烟相比哪个危害更大？