The new retail digital price tag solution is developed by Alibaba Cloud Message Queue for MQTT it is launched to realize the data update management of electronic tags and multimedia screens in shopping malls, supermarkets and public places through MQTT. This topic takes digital price tags as an example to describe the system architecture, data flow design, and other key components of the solution in detail. Other similar industries can refer to this solution, making modifications as necessary for implementation.
- Message Queuing Telemetry Transport (MQTT protocol)
- The MQTT protocol is an industry-standard protocol for the Internet of Things (IoT) and mobile Internet, which is suitable for data transmission between mobile devices. Message Queue for MQTT The MQTT protocol is supported by default.
- MQTT broker
- Message Queue for MQTT An MQTT broker is a broker node that interacts with the MQTT protocol and is used to receive and forward messages.
- MQTT client
- The MQTT client is the node used to interact with the MQTT broker. In this solution, it specifically indicates a smart access point for sending or receiving price change messages.
- P2P message
- Message Queue for MQTT A special type of message that is provided based on the standard MQTT protocol. This type of message can be directly sent to a specified target MQTT client without subscription matching. For more information, see P2P Messaging model (MQTT).
- Smart access point (AP)
- A common network device (such as a smart router) that supports application programming and can simultaneously handle Internet access and LAN device control functions.
- Digital price tags
- Electronic screens that are used in malls, supermarkets, and other places. They support networking based on wireless sensor network protocols (such as Bluetooth and ZigBee) as well as smart AP nodes for networking.
- Digital price tag management service
- The backend service of a digital price tag system. It is used to manage the content that is displayed on the electronic screens and to manage and query manual tasks, such as price changes.
- ApsaraDB for RDS
- A highly available and scalable online database service provided by Alibaba Cloud. It is used to make persistent the status changes of tasks (such as price changes) in a digital price tag system.
- Log Service
- The log storage service launched by Alibaba Cloud, which is used in a digital price tag system to persistently store all operation logs for auditing and tracing.
In digital price tag solutions, Message Queue for MQTT it can be used in conjunction with multiple Alibaba Cloud products to implement update management for price tag data.Figure 1 shows details on how the solution architecture of the digital price tag system works.
- The smart AP forwards the status data of the price tag and receives price change commands. The smart AP uses the MQTT SDK to access Alibaba Cloud Message Queue for MQTT over the public network based on the distribution of the stores or locations. This link uses SSL/TLS to encrypt transmissions, preventing data leaks.
- One smart AP downlink and several price tag nodes can communicate with each other through a wireless sensor network such as Bluetooth or ZigBee.
- The backend management service for digital price tags is deployed on the cloud based on ECS. Message Queue for Apache RocketMQ The SDK and Message Queue for Apache RocketMQ interaction.
- The backend management service for digital price tags can persistently change the status in the RDS databases when price changes and other tasks are performed. It can store price tag report data and operations logs to Log Service to facilitate tracing and auditing.
The advantages of the new retail digital price tag solution are as follows:
- Powerful service capabilities that can be scaled automatically.
- Message Queue for MQTT The message transmission capability is infinitely scalable, allowing you to increase the number of smart terminals without suffering from compromised system capabilities.
- Message Queue for MQTT Information pushing in milliseconds is supported for millions of devices, with an even smaller latency for display updates of digital price tags.
- Extensive application range, versatile generability, and rapid duplication.
- Based on the MQTT standard protocol, this solution is universally applicable. It can be replicated in similar scenarios by adapting the solution for different data content.
- High Reliability
- Message Queue for MQTT and smart AP nodes supports SSL/TLS encryption in data transmission, preventing media business data leakage.
- All service nodes are highly available and stable.
- The digital price tag node uses a periodic polling mechanism to exchange data with the smart AP node, reporting its current display status, power capacity, and other information.
- The smart AP node organizes data and sends MQTT messages to the MQTT broker.
- The MQTT broker writes the reported message to the Message Queue for Apache RocketMQ topic.
- The digital price tag management service receives Message Queue for Apache RocketMQ to process and analyze the status of online price tag nodes in the current system, and record the data to log service.
- The digital price tag management service sends a price change Message Queue for Apache RocketMQ message, triggering the price change operation.
- The MQTT Server routes the Message Queue for Apache RocketMQ to push messages to the target smart AP node by using the MQTT protocol.
- The smart AP node receives the price change notification and temporarily saves the task.
- The digital price tag node uses the polling mechanism to exchange data with the smart AP node and receives the new content to be displayed.
- After the target digital price tag node changes the price, the smart AP node returns an MQTT message to notify the digital price tag management service that the current task has been completed.
- The digital price tag management service writes the execution log of the current task to Service Log, facilitating subsequent tracing queries.
The preceding process briefly describes how to use Message Queue for MQTT and Message Queue for Apache RocketMQ to build the digital price tag system, please refer to Message Queue for MQTT and Message Queue for Apache RocketMQ document.
Where use Message Queue for MQTT and Message Queue for Apache RocketMQ when designing messages and parameters for transmitting commands, follow these principles:
- SDK and protocol selection
In the digital price tag scenario, one application may be used by hundreds of offline stores. Generally, each store is equipped with several smart AP nodes. The number of smart AP nodes can be increased as the business scales out. This makes smart AP nodes suitable for access by using the MQTT Protocol. The digital price tag management service is deployed on the cloud, Message Queue for Apache RocketMQ access.
- MQTT client ID mappingThe MQTT protocol requires that each client have a globally unique client ID. A client ID consists of two parts concatenated with the @@@ separator. The final client ID must be unique and its total length cannot exceed 64 characters. The following describes the two parts of a client ID:
- Prefix Group ID: The Group ID must be Message Queue for MQTT apply for the console. Group IDs can be roughly classified by platform vendor or channel to facilitate troubleshooting. For example, different industries or batches can be divided into different group IDs, or clients of different versions can use different group IDs.
- Device ID that is the suffix in a client ID: A device ID is generated by an application. Device IDs can be encoded by using the unique information, such as the MAC address of the smart AP node.
For more information about client IDs, see Terms.
- Topic name mapping
Use Message Queue for MQTT to send and receive messages, you must understand the publish /subscribe pattern of the MQTT Protocol. For more information, see agreement document and official documentation.The MQTT protocol is a message protocol based on the publish/subscribe pattern. The subscriptions and topics follow the directory tree format. Topics can be divided into parent topics and subtopics. The total length of a topic including the parent topic and subtopics cannot exceed 64 characters. The following describes the types of topics:
- Parent topic: The topic at the first level of the directory tree is a parent topic. The parent Topic must be Message Queue for MQTT can be used only after applying for permissions in the console. A Namespace is equivalent to a Namespace.
- Subtopic: A topic under a level-1 topic in the directory tree in MQTT is a subtopic. You can specify subtopics as needed without having to apply for them.
For more information about topics, see Terms.
When designing a topic for sending and receiving messages, you must comply with the following principles:
- Different types of tasks use different parent topics. For example, in this scenario, the price change tasks and the terminal status reporting tasks use different parent topics.
- In the digital price tag system, we recommend that you use Message Queue for MQTT P2P messages do not need to be subscribed, and the sender can directly specify the peer end to receive them. For more information, see P2P Messaging model (MQTT).
- Parameter design for message sending and receivingGenerally, price change tasks in the digital price tag scenario require real-time pushing. Therefore, we recommend that you configure the smart AP as follows during the interactions between the smart AP and the MQTT broker to ensure that the smart AP does not need to process the tasks that were pushed when it was disconnected:
- cleanSession set the parameter to "tru e”.
- Set QoS to 1 ".
For more information about CleanSession and QoS, see Terms.