MQ, as a message-oriented middleware launched by OneNET, can transmit device messages to application services efficiently and reliably, and is widely applied to smart homes, sharing economy, smart parks, smart cities and other industries, helping users to address push notification, distribution and other needs, and ensuring instant and reliable data interaction between user application platform and OneNET.
In many scenarios involving timely notification of and reply to messages, such as smoke alarm and sharing economy, user application systems should retrieve messages in a timely manner. MQ provides an efficient data channel for the application layer to retrieve messages from a device so as to realize millisecond-level end-to-end real-time data synchronization.
Taking sharing economy as an example, a shared charging solution provider can realize long-lived connections and real-time command and control via OneNET. When retrieving messages, the business system of the solution provider can choose HTTP push and message queue, and message queue has the characteristics of low latency, which can eliminate message loss and effectively ensure data consistency and integrity.
Compared with OneNET’s HTTP push that serves push scenarios, MQ has the following advantages:
Item | HTTP Push | Message queue (MQ) |
---|---|---|
Message buffer | Not Supported | Supported |
Clustering | Load Balanced Applications | Supported |
Backtrack | Not Supported | Supported |
Multi-party consumption | Not Supported | Support OneToMany |
Latency | High | Low |
In such industries as smart city and smart meter, there will be multiple application systems that need to connect device data, so it is necessary to distribute messages from one device to different application systems. Since MQ supports OneToMany, messages can be flexibly distributed to one or more consumers.
After a smart meter supplier's device is connected to OneNET, its messages should interface with multiple sub-application service systems. After a device uploads messages, the following actions may happen to associated application service systems:
The above application service systems are independent and do not need to wait for the processing results of other modules. Because MQ supports multi-party independent consumption, it can fully meet the requirements for this business scenario. If new businesses are also asking for connection with such messages, they just have to subscribe to the messages, which has no impact on existing businesses.
In application scenarios like smart home, sharing economy and smart park, a transient traffic peak occurs when a device is used intensively, which will impact much on the application system. MQ buffers the peak, ensuring smooth customer operations and reducing costs.
A sharing economy solution provider, for example, may launch Seckill promotion during major festivals. The main business processes are as follows:
If a large number of Seckill requests are sent directly to the application system, it may impact on the system.
After MQ is introduced, Seckill requests generated within a short time are stored in the message queue, and then processed when the application system has the capacity to do it, which reduces the processing pressure of the application system and achieves load shifting.