停车设备接了MQTT，就能断网不丢单？把这几个概念分开看

方案书上写着MQTT，供应商说支持消息推送、断线重连和离线缓存。

听起来，停车场掉线、丢记录和开闸慢的问题，好像都解决了。

MQTT提供的是消息通信机制。订单能否完整、费用是否正确、控制是否安全，还取决于整套系统怎样实现。

这个区别，选型时一定要问清楚。

01 它怎样让设备和后台沟通

MQTT采用发布订阅模式。设备把消息发布到相应主题，消息代理按订阅关系转发给接收方。

设备可以上报状态和事件，平台也可以通过约定主题下发配置或控制。主题如何命名、消息包含什么、谁有权限收发，需要项目自己设计。

它适合物联网事件通信，但不是所有停车设备都使用它，也不是用了它就一定比别的方案稳定。

02 HTTP和MQTT 可以分工合作

HTTP是请求响应的通信方式，但并不只能短连接或被动轮询；设备也可以通过HTTP接口主动上报。

停车应用中，设备消息、图片上传、页面查询和支付接口，可以采用不同方式。大图片经HTTPS等方式上传，MQTT携带事件与图片引用，就是一种可评估的设计。

不能把“有消息代理”和“接口协议”简单排成先进与落后。实现、负载和故障处理同样重要。

消息代理负责转发；业务落库、计费与控制结果仍需系统核验。

03 QoS解决哪一段 不解决哪一段

MQTT有不同消息交付等级。QoS 0允许消息丢失；QoS 1可能出现重复；QoS 2在协议交付层提供更强的去重交付语义。

但“对方收到消息”不等于“停车订单已经成功提交数据库”，更不等于“闸杆正确完成动作”。

因此，订单和通行事件仍应有业务标识、幂等处理和结果核对。幂等的意思很简单：同一事件重复送来，不应多生成一笔账。

04 三种缓存 别混为一谈

设备自身未发出的记录，需要本地持久化安排；代理保存的会话与待发消息，受会话设置、QoS、容量及有效期等条件影响。

保留消息通常用于提供主题的最近状态，不是完整的历史记录仓库。

网络恢复后补传，还要处理重复、乱序、设备时间和缓存满等情况。不能把“支持MQTT”直接写成“断网期间所有数据不丢不错”。

05 开闸指令尤其要防止过时执行

设备重连后，不能把很久以前的开闸请求当作当前请求执行。

应核对指令有效期、对象、权限、唯一标识及执行回执；具体处理机制要由系统设计并验证。不要把开闸动作简单当成需要永久保留的“最新状态”。

通信加密、设备身份和主题权限，也要单独配置。协议名称本身不会替你完成安全管理。

用重复、断连、过期与恢复场景验证业务结果。

06 验收时 比一句支持更有用的是演示

请演示断网时记录存在哪、容量到限怎样处理、重启后是否还在，以及恢复后怎样去重核对。

再验证无权限设备不能随意发布控制消息，过期指令不会被补执行。

MQTT是工具。停车系统是否可靠，要从消息一直查到业务结果。

下次看到“支持MQTT”，不妨多问一句：支持到哪一层，哪些结果已经验证？

— 鑫禾智城 —

关注鑫禾智城，把协议能力与现场效果分开讲清楚。

参考：OASIS MQTT 5.0规范。配图为 AI 场景插画与原创技术图，均仅作示意。