新零售电子价签解决方案由阿里云微消息队列 MQTT 版推出,通过 MQTT 以实现商场超市、公共场所电子标签、多媒体屏幕的数据更新管理。本文将以电子价签为例详细描述该解决方案的系统架构、数据流设计以及注意事项,其他类似行业可参考该方案修改适配。
名词解释
- MQTT
- 一种物联网和移动互联网领域的行业标准协议,适合移动终端之间的数据传输。微消息队列 MQTT 版默认支持该协议。
- MQTT 服务器
- 微消息队列 MQTT 版提供的 MQTT 协议交互的服务端节点,用于接收消息并转发消息。
- MQTT 客户端
- 用于和 MQTT 服务器交互的节点,本方案中特指发送或接收价格变更消息的智能 AP。
- P2P 消息
- 微消息队列 MQTT 版在标准的 MQTT 协议基础上提供的一种特殊消息,该类型消息无需普通的订阅关系匹配,便可直接发送给指定的单个目标 MQTT 客户端。详情请参见 P2P 消息收发模式(MQTT)。
- 智能 AP
- 市面常见的智能路由器等网络设备,支持应用编程,可以同时承担互联网接入以及局域网设备控制等工作。
- 电子价签
- 实际分布在商场超市等场所中的电子显示屏幕,一般使用蓝牙、ZigBee 等无线传感网络协议和智能 AP 节点组网。
- 电子价签管控服务
- 电子价签系统中用于管理电子屏幕显示内容的后台服务,主要承担改价等人工操作的任务管理和查询工作。
- RDS
- 阿里云推出的一种稳定可靠、可弹性伸缩的在线数据库服务。在电子价签系统中用来持久化改价等任务的状态变更。
- SLS 日志存储
- 阿里云推出的日志存储服务,在电子价签系统中用来持久化保存所有操作日志,用于审计和溯源。
方案架构
在电子价签解决方案中,微消息队列 MQTT 版与阿里云多个产品结合使用,实现价签的数据更新管理。图 1 展示了针对电子价签系统的解决方案架构。

- 智能 AP 负责转发上报价签的状态数据,并接收改价指令。智能 AP 按照门店或者场所分布,内部使用 MQTT SDK 从公网接入阿里云微消息队列 MQTT 版,该链路采用 SSL/TLS 加密传输,防止数据泄露。
- 一个智能 AP 下行链路和若干价签节点通过蓝牙、ZigBee 等无线传感网络协议组网,完成局域网内部数据交互。
- 电子价签后台管理服务部署在云端(云服务 ECS),使用消息队列 RocketMQ 版的 SDK 和消息队列 RocketMQ 版交互,MQTT 服务端和 RocketMQ 服务端天然互通。
- 电子价签后台管理服务可以将改价等任务的状态变更持久化到 RDS 数据库以确保任务变更成功,并将价签上报数据和操作日志存储到 SLS,方便溯源和审计。
方案优势
新零售电子价签解决方案的优势如下所述:
- 服务能力强,可弹性伸缩
- 微消息队列 MQTT 版消息传输能力无限扩展,智能终端数量增加无需担心系统能力不足。
- 微消息队列 MQTT 版支持百万级设备毫秒级推送完成,电子价签屏显更新延迟更小。
- 适用范围广,通用性好,可快速复制
- 基于 MQTT 标准协议实现,通用性好,方案只需简单适配数据内容即可快速复制到其他相似场景。
- 安全可靠
- 微消息队列 MQTT 版服务和智能 AP 节点数据传输支持 SSL/TLS 加密,无需担心媒体商业数据泄露。
- 所有服务节点高可用,稳定性高。
数据交互
状态上报
- 电子价签节点会采用定时轮询机制和智能 AP 节点交换数据,上报自己当前的显示状态、节点电量等信息。
- 智能 AP 节点组织数据,并发送 MQTT 消息到 MQTT 服务器。
- MQTT 服务器会将上报消息写入业务方指定的消息队列 RocketMQ 版 Topic。
- 电子价签管控服务通过接收消息队列 RocketMQ 版消息,处理分析当前系统中在线的价签节点的状态,并将数据记录到 SLS。
更新屏显
- 电子价签管控服务发送改价的消息队列 RocketMQ 版消息,触发改价操作。
- MQTT 服务端会路由该消息队列 RocketMQ 版消息,将消息通过 MQTT 协议推送给目标智能 AP 节点。
- 智能 AP 节点收到改价通知,将任务暂存。
- 电子价签节点会采用轮询机制和智能 AP 节点交换数据,感知新的屏显内容。
- 目标电子价签节点改价成功后,智能 AP 节点回发一条应答 MQTT 消息,通知电子价签管控服务当前任务已完成。
- 电子价签管控服务将当前任务的执行记录写入 SLS 日志,方便后续溯源查询。
注意事项
上述流程简要描述了如何使用微消息队列 MQTT 版和消息队列 RocketMQ 版来搭建电子价签系统,具体的 SDK 说明请参见微消息队列 MQTT 版以及消息队列 RocketMQ 版文档。
其中使用微消息队列 MQTT 版和消息队列 RocketMQ 版进行指令传输时,相关的消息类型设计以及参数设计请尽可能遵循如下原则:
- SDK 和协议选择
电子价签场景中,一个应用可能存在成百上千的线下门店,一般每个门店配备若干个智能 AP 节点,智能 AP 节点会随着业务规模上升而增加,所以智能 AP 节点适合使用 MQTT 协议接入,而电子价签管控服务由于部署在云端,适合使用云上的消息队列 RocketMQ 版接入。
- 客户端 ID 映射MQTT 协议要求每个客户端都有一个全局唯一的 Client ID,Client ID 由以下两部分组成,这两部分通过 “@@@” 分隔符连接,只需要保证最终的 Client ID 唯一且总长度不超过 64 个字符即可:
- 前缀 Group ID:Group ID 需在微消息队列 MQTT 版控制台申请。Group ID 按照平台供应商或者渠道进行粗分类,例如不同的行业、批次分成不同的 Group ID,或者不同版本的客户端使用不同的 Group ID,方便问题定位。
- 后缀 Device ID:Device ID 由应用生成。Device ID 可以使用智能 AP 节点的 MAC 地址等唯一性信息编码。
Client ID 的更多信息请参见名词解释。
- Topic 名称映射
使用微消息队列 MQTT 版收发消息需要了解 MQTT 协议订阅关系的模型,详情请参见协议文档和官网文档。
MQTT 是遵循发布/订阅模型的消息协议,订阅关系和 Topic 符合目录树格式,Topic 可分为父级 Topic 和子级 Topic,Topic(包含父级 Topic 和子级 Topic)的总长度不能超过 64 个字符:- 父级 Topic:通常称目录树第一级的 Topic 为父级 Topic。父级 Topic 需要在微消息队列 MQTT 版控制台申请后才可使用,申请后相当于一个 Namespace。
- 子级 Topic:目录树第一级的 Topic 的后续部分称为子级 Topic。子级 Topic 无需申请,业务方可以随意指定。
Topic 的更多信息请参见名词解释。
业务方设计用于消息收发的 Topic 时,需要遵循以下原则:
- 不同类型的任务使用不同的父级 Topic,例如本场景中,改价任务和终端状态上报使用不同的父级 Topic。
- 对于电子价签系统中,改价任务的交互消息建议使用微消息队列 MQTT 版提供的 P2P 消息,P2P 消息不需要订阅,发送方直接指定对端接收即可,详情请参见 P2P 消息收发模式(MQTT)。
- 收发消息参数设计由于电子价签场景改价任务一般要求实时推送,建议在智能 AP 和 MQTT 服务器交互过程中,智能 AP 做以下配置,以确保智能 AP 无需处理掉线期间的任务:
- cleanSession 参数设置为 “true”。
- QoS 设置成 “1”。
cleanSession 和 QoS 的更多信息,请参见名词解释。
在文档使用中是否遇到以下问题
更多建议
匿名提交