CN115988058A - A message processing method, device, electronic device, and computer-readable medium - Google Patents

Abstract

The application discloses a message processing method, device, electronic equipment, and computer-readable medium, which relate to the technical field of the Internet of Things, and in particular to the technical field of network and communication. A specific implementation method includes obtaining the corresponding user identification in response to the detection of payment transaction data and terminal ID, and then generate a broadcast message; based on the user ID and terminal ID, determine the target cloud broadcast device; obtain the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online; call the target cloud broadcast device to execute The broadcast task, in response to detecting a network anomaly when executing the broadcast task, invokes the connection service to repair the network anomaly and re-executes the broadcast task until the execution is successful, and outputs broadcast result information. Relatively cheap equipment can be used to reduce costs. Improve the success rate of task execution, improve the efficiency of message processing, and ensure the timeliness of message processing.

Description

A message processing method, device, electronic device, and computer-readable medium

technical field

The present application relates to the technical field of the Internet of Things, in particular to the technical field of network and communication, and in particular to a message processing method, device, electronic equipment and computer-readable medium.

Background technique

Mobile payment has been widely popularized in recent years, and has become the main payment method for many consumers in daily life. Mobile payment mainly includes two-dimensional code payment, quick payment, jumping to third-party client payment, etc. For an unstable network, it is impossible to recover from a disconnected fault natively, resulting in a high failure rate of task execution, and after the user's payment is successful, the seller cannot be notified immediately at the first time, resulting in untimely message processing and low efficiency. Low.

Contents of the invention

In view of this, the embodiments of the present application provide a message processing method, device, electronic device, and computer-readable medium, which can solve the existing problems of high task execution failure rate, untimely message processing, and low efficiency.

To achieve the above purpose, according to an aspect of the embodiment of the present application, a message processing method is provided, including:

In response to detecting the payment transaction data, obtain the corresponding user ID and terminal ID, and then generate a broadcast message;

Determine the target cloud broadcast device based on the user ID and the terminal ID;

Obtain the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online;

Invoking the target cloud broadcast device to execute the broadcast task, in response to detecting a network anomaly during the execution of the broadcast task, invoking the connection service to repair the network anomaly and re-executing the broadcast task until the execution is successful, outputting broadcast result information.

Optionally, a broadcast message is generated, including:

Call the distributed message queue to determine the target consumption partition from the corresponding consumption partition set;

Call the target consumption partition to generate a broadcast message based on the user ID and terminal ID.

Optionally, determine the target cloud broadcast device, including:

Determine the cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and the terminal identifier;

Obtain the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to one or more device identifiers;

Determine the target cloud broadcast device based on the number of unexecuted broadcast tasks.

Optionally, based on the number of unexecuted broadcast tasks, the target cloud broadcast device is determined, including:

Incrementally sort the number of unexecuted broadcast tasks;

The cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first is determined as the target cloud broadcast device.

Optionally, call the target cloud broadcast device to perform the broadcast task, including:

In response to the current time reaching the preset execution time corresponding to the broadcast task, formatting the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device;

Call the target cloud broadcast device to broadcast the message that the target cloud broadcast device can parse;

Output the message processing result message.

Optionally, after outputting the message processing result message, the method further includes:

Parse the message processing result message to obtain the broadcast task message number, processing result status and failure description field value;

Update the target cloud broadcast device log based on the broadcast task message number, processing result status and failure description field value.

Optionally, after detecting that the network is abnormal when executing the broadcast task, calling the connection service to repair the network abnormality and re-executing the broadcast task until the execution is successful, and outputting the broadcast result information, the method further includes:

In response to the broadcast task being the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, the update status is offline.

In addition, the present application also provides a message processing device, including:

The obtaining unit is configured to obtain the corresponding user identification and terminal identification in response to the detection of the payment transaction data, and then generate a broadcast message;

The device determination unit is configured to determine the target cloud broadcast device based on the user identification and the terminal identification;

The task generation unit is configured to obtain the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online;

The execution unit is configured to call the target cloud broadcast device to execute the broadcast task, and in response to detecting a network anomaly when performing the broadcast task, call the connection service to repair the network anomaly and re-execute the broadcast task until the execution is successful, and output the broadcast result information.

Optionally, the acquisition unit is further configured to:

Call the distributed message queue to determine the target consumption partition from the corresponding consumption partition set;

Call the target consumption partition to generate a broadcast message based on the user ID and terminal ID.

Optionally, the device determination unit is further configured to:

Determine the cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and the terminal identifier;

Obtain the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to one or more device identifiers;

Determine the target cloud broadcast device based on the number of unexecuted broadcast tasks.

Optionally, the device determination unit is further configured to:

Incrementally sort the number of unexecuted broadcast tasks;

The cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first is determined as the target cloud broadcast device.

Optionally, the execution unit is further configured to:

In response to the current time reaching the preset execution time corresponding to the broadcast task, formatting the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device;

Call the target cloud broadcast device to broadcast the message that the target cloud broadcast device can parse;

Output the message processing result message.

Optionally, the execution unit is further configured to:

Parse the message processing result message to obtain the broadcast task message number, processing result status and failure description field value;

Update the target cloud broadcast device log based on the broadcast task message number, processing result status and failure description field value.

Optionally, the message processing device further includes a status update unit configured to:

In response to the broadcast task being the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, the update status is offline.

In addition, the present application also provides a message processing electronic device, including: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, One or more processors are made to implement the above message processing method.

In addition, the present application also provides a computer-readable medium, on which a computer program is stored, and when the program is executed by a processor, the above message processing method is realized.

To achieve the above purpose, according to still another aspect of the embodiments of the present application, a computer program product is provided.

A computer program product according to an embodiment of the present application includes a computer program, and when the program is executed by a processor, the message processing method provided in the embodiment of the present application is implemented.

An embodiment of the above invention has the following advantages or beneficial effects: the application obtains the corresponding user ID and terminal ID in response to the detection of payment transaction data, and then generates a broadcast message; based on the user ID and terminal ID, determine the target cloud broadcast equipment; obtain the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online; call the target cloud broadcast device to perform the broadcast task, and in response to detecting that the network is abnormal when performing the broadcast task, call the connection service to Repair the network anomaly and re-execute the broadcast task until the execution is successful, and output the broadcast result information. Relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

The further effects of the above-mentioned non-conventional alternatives will be described below in conjunction with specific embodiments.

Description of drawings

The accompanying drawings are used for better understanding of the present application, and do not constitute an improper limitation of the present application. in:

FIG. 1 is a schematic diagram of a main flow of a message processing method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a main flow of a message processing method according to an embodiment of the present application;

FIG. 3 is a schematic flowchart of a main message processing method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a system architecture of a message processing method according to an embodiment of the present application;

Fig. 5 is a schematic diagram of main units of a message processing device according to an embodiment of the present application;

FIG. 6 is an exemplary system architecture diagram to which the embodiment of the present application can be applied;

Fig. 7 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present application.

Detailed ways

Exemplary embodiments of the present application are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present application to facilitate understanding, and they should be regarded as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness. It should be noted that in the technical solution of this application, the collection, analysis, use, transmission, storage, etc. of the user's personal information involved are in compliance with the relevant laws and regulations, and are used for legal and reasonable purposes. Sharing, divulging or selling other than legitimate use, and accepting the supervision and management of regulatory authorities. Necessary measures should be taken for users' personal information to prevent illegal access to such personal information and data, ensure that those who have access to personal information and data abide by relevant laws and regulations, and ensure the security of users' personal information. Risk should be minimized by limiting or even prohibiting data collection and/or deleting data once such user personal data is no longer required.

When used, including in certain related applications, to protect user privacy by de-identifying data, such as by removing specific identifiers at the time of use, controlling the amount or specificity of stored data, controlling how data is stored, and/or other methods to de-identify.

Fig. 1 is a schematic diagram of the main flow of a message processing method according to an embodiment of the present application. As shown in Fig. 1, the message processing method includes:

Step S101, in response to the detection of payment transaction data, obtain the corresponding user ID and terminal ID, and then generate a broadcast message.

In this embodiment, the execution subject of the message processing method (for example, it may be a server) may detect whether payment transaction data exists through a wired connection or a wireless connection. When the payment transaction data is detected, the execution subject can obtain the corresponding user ID. Specifically, the user identifier may be the account name or user name or merchant number of the user who triggers the generation of the payment transaction data, and the embodiment of the present application does not specifically limit the user identifier. The execution subject can also obtain the terminal identification corresponding to the payment transaction data. The terminal identification can be, for example, the product serial number (SN number) of the handheld terminal or the Bluetooth address of the handheld terminal of the user who triggered the generation of the payment transaction data. The content and type of are not specifically limited. The execution subject can call the message generation program to generate a broadcast message according to the payment transaction data (for example, y yuan), user identification (for example, a) and terminal identification (for example, there is a payment transaction between c and payment terminal d). For example, the broadcast message may be "d received a payment of y yuan from a, please pay attention to check".

Step S102, based on the user ID and the terminal ID, determine the target cloud broadcast device.

When the user ID is the merchant ID, the terminal ID is the merchant's mobile terminal SN. The execution subject can query the merchant-bound device information according to the user ID and terminal ID. Exemplarily, the device may be a speaker for broadcasting information.

For example, merchant personnel can scan the QR code of the speaker base through the mobile terminal H5 or enter the system through a link, and confirm whether the merchant and the device are bound through the SN number of the merchant’s mobile terminal and the SN number of the speaker. Specifically, the business personnel scan the QR code of the speaker base through the mobile terminal H5 or click the link on the mobile terminal H5 page to enter the message processing system. Follow the prompts to enter the message processing system by scanning the QR code to obtain the merchant number and the SN number of the speaker. The speaker binding information management module can call the merchant information query interface to check whether the incoming merchant number exists. If it does not exist, it will prompt the merchant. Does not exist, if it exists, continue to judge whether the speaker is bound by other merchants, if it is bound by other merchants, it will prompt that the speaker has been bound by other merchants and jump to the cloud broadcast device list page to display all the clouds that can be selected by the merchant number sent Broadcast equipment for merchants to choose to use. If it is not bound by other merchants, it will be judged whether the speaker has been bound to the merchant number sent. If it has been bound, it will jump to the cloud broadcast device list and query the speaker corresponding to the SN number of the speaker sent by default. is the target cloud broadcast device). If there is no merchant ID bound, jump to the cloud broadcast device binding page to bind the speaker corresponding to the SN number of the speaker.

It is understandable that if the user ID corresponds to a unique terminal ID, for example, when the merchant number has a unique SN number of a handheld mobile phone, the execution subject can simultaneously check whether the speaker corresponding to the speaker SN number is bound based on the user ID and the terminal ID, For example, when the user ID is bound to the speaker SN number, continue to check whether the unique terminal ID corresponding to the user ID has also been bound to the speaker corresponding to the speaker SN number. The result obtained by specifying the speaker corresponding to the SN number of the speaker is more accurate. Among them, the way to obtain the speaker SN number can include manual input or scanning code acquisition. For example, the merchant scans the QR code on the speaker base to jump to the cloud broadcast device binding page to automatically bring up the speaker SN number. Scan the code on the login page to obtain the user ID (such as the merchant ID) and automatically bring out the terminal ID (such as the terminal ID). And use the user ID and the terminal ID to determine the target cloud broadcast device, such as a target speaker for message broadcast.

Step S103, acquiring the status of the target cloud broadcast device, and generating a broadcast task based on the broadcast message in response to the status being online.

MQTT protocol: The full name of MQTT (Message Queuing Telemetry Transport Protocol) is the abbreviation of Message Queue Remote Sensing Transport Protocol. Provide orderly, reliable, two-way connection network connection guarantee. The target cloud broadcast device, such as the target speaker. After the execution subject determines the target cloud broadcast device, it can obtain the status of the target cloud broadcast device, such as whether it has been bound with the current user, whether it has been bound with other users, etc., and prompts that the cloud broadcast device has been bound with the current user. The current cloud broadcast device is bound. If it is not bound to the current user, it will continue to judge whether the speaker is bound to other users. When it is bound to other users, it will prompt that the cloud broadcast device has been bound to other users. When the user ID is not bound to other users, other candidate terminal IDs corresponding to the user IDs are obtained. Specifically, the candidate terminal IDs can be obtained through manual input or code scanning. Furthermore, after obtaining the candidate terminal ID, the execution subject can judge whether the terminal ID on the binding page of the cloud broadcast device is bound based on the candidate terminal ID is repeatedly added, and if so, prompts not to bind the terminal device repeatedly, otherwise, pass the user ID, Candidate terminal identification, speaker SN number, speaker name, remark information to the speaker binding information management module, and then the speaker binding information management module sends the manufacturer number corresponding to the speaker SN number to the white list module to determine the speaker SN corresponding Whether the manufacturer is in the white list, if not in the white list, it will prompt the cloud to broadcast the information that the device has not been registered in the background, if it is in the white list, save the binding relationship between the SN number of the speaker, the user ID and the candidate terminal ID, and generate the speaker The MQTT user password of the cloud broadcast device corresponding to the SN number, topic name, topic operation authority (readable and writable), public key and private key for encryption and decryption of messages pushed by both parties are stored in the remote dictionary service redis database. Then, it prompts the binding success information, and jumps to the cloud broadcast device list page to query the device list according to the latest binding time of the cloud broadcast device.

After the target cloud broadcast device is successfully bound to the terminal identifier (for example, a candidate terminal identifier) corresponding to the user identifier, it can be determined that the target cloud broadcast device is online and can be called at any time to perform message broadcast. At this point, the execution subject can generate a broadcast task for the target cloud broadcast device to execute according to the broadcast message.

Step S104, calling the target cloud broadcasting device to execute the broadcasting task, in response to detecting a network abnormality during the execution of the broadcasting task, calling the connection service to repair the network abnormality and re-executing the broadcasting task until the execution is successful, and outputting broadcast result information.

Each broadcast task may have a corresponding execution time, and the execution time may be real-time or every preset time.

Specifically, invoking the target cloud broadcast device to execute the broadcast task includes: in response to the current time reaching the preset execution time corresponding to the broadcast task, formatting the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device, for example , when the target cloud broadcast device is a speaker, the message message corresponding to the broadcast task can be formatted into a data format that the speaker can better parse. Invoke the target cloud broadcast device to broadcast the message that the target cloud broadcast device can parse. Specifically, it can push the message that the target cloud broadcast device can parse (such as a message in a data format that the speaker can parse) to the broadcast message receiving topic for the corresponding speaker pair to subscribe to. Broadcast the messages in the message receiving topic for message consumption; then output the message processing result message.

MQTT protocol: The full name of MQTT (Message Queuing Telemetry Transport Protocol) is the abbreviation of Message Queue Remote Sensing Transport Protocol. Provide orderly, reliable, two-way connection network connection guarantee. When it is detected that the network is abnormal during the execution of the broadcast task, call the connection service, such as the MQTT connection service, to repair the network abnormality and re-execute the broadcast task until the execution is successful, and output the broadcast result information.

This embodiment obtains the corresponding user ID and terminal ID in response to the detection of payment transaction data, and then generates a broadcast message; based on the user ID and terminal ID, determines the target cloud broadcast device; obtains the state of the target cloud broadcast device, and responds to the state To be online, generate a broadcast task based on the broadcast message; call the target cloud broadcast device to perform the broadcast task, and in response to detecting that the network is abnormal when performing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until the execution is successful , output broadcast result information. Relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

Fig. 2 is a schematic flow diagram of a main flow of a message processing method according to an embodiment of the present application. As shown in Fig. 2, the message processing method includes:

Step S201, in response to detecting the payment transaction data, obtain the corresponding user ID and terminal ID.

The payment transaction data may be, for example, transaction data generated by a user paying for commodity consumption at a merchant.

The user identifier may be a merchant code, and the terminal identifier may be a serial number of a merchant's terminal product (for example, the SN number of a merchant's POS machine).

Step S202, calling the distributed message queue to determine the target consumption partition from the corresponding consumption partition set.

Distributed message queues such as kafka, kafka classifies messages according to topics when saving them. The message sender is called Producer, and the message receiver is called Consumer. In addition, the kafka cluster consists of multiple kafka instances, and each instance (server) is called It is the broker (that is, the kafka server). A topic contains multiple partitions, and each partition is a separate directory. For example, the partition naming rule is topic + sequence number, for example, from zero to partition n-1. In the embodiment of this application, as an example, Kafka can be configured with 30 partitions and one topic. The execution subject can call the consumer thread to randomly extract partitions (or according to the specified partition) as the target consumption partition for message consumption.

Step S203, invoking the target consumption partition to generate a broadcast message based on the user ID and the terminal ID.

Calling the consumer thread to randomly extract partitions as the target consumption partition for consumption can be to call the target consumption partition to obtain payment transaction data, and according to the user identification (such as a), terminal identification (for example, there is a payment transaction between c and payment terminal d) and payment The transaction data (eg y) generates a broadcast message (eg "d received a payment of y yuan from a, please check").

Step S204, based on the user ID and the terminal ID, determine the target cloud broadcast device.

When the number of terminal identities corresponding to the user id is multiple, for example, 2 or more, the priority of the terminal identities set by the user can be obtained, and then the candidate cloud broadcast device list can be determined according to the priority. Then, the executive body can sequentially determine whether the terminal ID has a bound cloud broadcast device according to the priority. If the terminal ID corresponding to the highest priority has a bound cloud broadcast device, such as cloud broadcast device Q, the cloud broadcast device can be Broadcasting device Q is determined as the target cloud broadcasting device. If the terminal ID corresponding to the highest priority does not have a bound cloud broadcast device, update the second highest priority to the highest priority, and if the terminal ID corresponding to the second highest priority does not have a bound cloud broadcast device, the The next highest priority is updated to the highest priority until the terminal ID corresponding to the updated highest priority has a bound cloud broadcast device bit.

Step S205, acquiring the status of the target cloud broadcast device, and generating a broadcast task based on the broadcast message in response to the status being online.

The status of the target cloud broadcast device, such as a speaker, can be bound and online, bound and offline, unbound and online, unbound and offline, etc. The embodiment of the present application broadcasts to the target cloud The state of the device is not specifically limited.

In response to the state of the target cloud broadcast device being bound and online, a broadcast task is generated based on the broadcast message. The broadcast task may be a task executed synchronously or asynchronously, and the embodiment of the present application does not specifically limit the type of the broadcast task.

Step S206, calling the target cloud broadcasting device to execute the broadcasting task, in response to detecting a network abnormality during the execution of the broadcasting task, calling the connection service to repair the network abnormality and re-executing the broadcasting task until the execution is successful, and outputting the broadcasting result information.

Call the target cloud broadcast device to execute the corresponding broadcast task according to the time and type of the broadcast task, in response to detecting a network anomaly when executing the broadcast task, call the connection service to repair the network anomaly and re-execute the broadcast task until the execution is successful , output broadcast result information. For example, the broadcast result information may include the broadcast task message number, processing result information, failure description information, etc., and the embodiment of the present application does not specifically limit the broadcast result information.

Specifically, after outputting the message processing result message, the message processing method further includes: parsing the message processing result message to obtain the broadcast task message number, processing result status and failure description information field value; Status and failure description field values update the target cloud broadcast device log.

In this embodiment of the present application, relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

Fig. 3 is a schematic flowchart of a main message processing method according to an embodiment of the present application. As shown in Fig. 3, the message processing method includes:

Step S301, in response to detecting the payment transaction data, obtain the corresponding user ID and terminal ID.

The payment transaction data may be house rental transaction data. The user identifier may be the name of the user who rents the house corresponding to the house-renting transaction data, and the like. The terminal identifier may be the serial number (eg SN number) of the handheld terminal product corresponding to the renting user.

Step S302, calling the distributed message queue to determine the target consumption partition from the corresponding consumption partition set.

The distributed message queue can determine an idle partition from the set of consumption partitions, and then determine the idle partition as the target consumption partition.

Step S303, calling the target consumption partition to generate a broadcast message based on the user ID and the terminal ID.

The target consumption partition can call the message generation program to generate a corresponding broadcast message according to the user ID, terminal ID, and payment transaction data.

Step S304, determining the cloud broadcast device corresponding to one or more device identifiers bound with the user identifier and the terminal identifier.

Step S305, acquiring the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to one or more device identifiers.

Step S306, based on the number of unexecuted broadcast tasks, determine the target cloud broadcast device.

When the user ID and the terminal ID are bound to one or more cloud broadcast devices, the target cloud broadcast can be determined according to the number of tasks to be broadcast (that is, the number of unexecuted broadcast tasks) in the one or more cloud broadcast devices equipment. For example, the bound cloud broadcast device with the least number of tasks to be broadcast may be determined as the target cloud broadcast device, so as to improve the execution efficiency of the broadcast task.

Specifically, based on the number of unexecuted broadcast tasks, determining the target cloud broadcast device includes: sorting the number of unexecuted broadcast tasks incrementally; The cloud broadcast device with the least number) is determined as the target cloud broadcast device.

Step S307, acquiring the status of the target cloud broadcast device, and generating a broadcast task based on the broadcast message in response to the status being online.

The number of target cloud broadcasting devices can be one or more. When the number of target cloud broadcasting devices is multiple, the execution subject can query the device information to determine the online status of the target cloud broadcasting device, and based on the online status of the target cloud broadcasting device The SN number of the cloud broadcast device generates a broadcast task based on the broadcast message. Adding the SN number to the broadcast task can make the execution device of the broadcast task clearer, and avoid the confusion of the device performing the task.

When querying device information, for example, merchants can query the list of cloud broadcast devices through the H5 page of the mobile terminal, query the information bound to the device according to the SN number of the speaker, and then determine the status of the device. For example, the merchant clicks on a speaker on the H5 cloud broadcast device list page on the mobile terminal, obtains the speaker SN, and sends the speaker SN to the speaker binding information management module to determine whether the speaker exists. If not, it prompts that the cloud broadcast device does not exist And then jump to the cloud broadcast device list page, if so, query the detailed information of the speaker based on the SN number of the speaker, and send the detailed information of the speaker (such as the name of the speaker, the SN number of the speaker, whether the status of the speaker is online or offline), as well as the merchant number, remarks, terminal The number is displayed on the H5 cloud broadcast device details page on the mobile terminal.

Step S308, calling the target cloud broadcasting device to execute the broadcasting task, in response to detecting a network abnormality during the execution of the broadcasting task, calling the connection service to repair the network abnormality and re-executing the broadcasting task until the execution is successful, and outputting broadcast result information.

Specifically, in response to detecting a network anomaly when executing the broadcast task, calling the connection service to repair the network anomaly and re-executing the broadcast task until the execution is successful, after outputting the broadcast result information, the message processing method further includes: responding to the broadcast The task is the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, and the update status is offline.

For example, after the cloud broadcast device is shut down and offline, push the offline subject, and update the cloud broadcast device to the offline state, that is, the offline state. For example, if the cloud broadcast device is a speaker, and the speaker is disconnected, the speaker offline message is pushed to the device offline topic ① through the message queue remote sensing transmission protocol (MQTT protocol). The cloud broadcast device management service system obtains the client ClientId and the speaker SN number and Send it to the speaker binding information management module, and the speaker binding information management module updates the speaker as offline and saves the updated offline status of the speaker to the redis database.

In this embodiment of the present application, relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

In one embodiment of the present application, after the consumer scans the code for payment, he pushes all payment transaction data through the push module. The transaction data includes the merchant number and terminal number (such as POS machine, counter number, etc.). Large, 30 partitions are divided through the kafka message queue, and the consumer thread randomly selects the partitions for consumption, and completes the message push according to whether the merchant is bound to the cloud broadcast device. The speaker scheduling module receives the message pushed by the kafka message queue and parses to obtain information such as the merchant number and terminal number, and sends the merchant number and terminal number to the speaker information binding module to obtain the merchant, merchant terminal and speaker based on the merchant number and terminal number The binding information is stored in the redis database. After the cloud broadcast device (such as a speaker) is bound to the merchant, it can be bound by selecting the payment terminal under the merchant's name to push the broadcast message. During the binding process, it is also necessary to verify whether the terminal number is added repeatedly to ensure that the message push accuracy. The speaker information binding module filters and judges whether the merchant and the merchant terminal are bound with a speaker. If not, it does not push the broadcast message. If so, it continues to judge whether the speaker is online. If it is not online, it does not push the broadcast message. If it is online, the main body calls the speaker scheduling. The module sends information such as the global serial number, merchant number, order number, speaker SN number, data source, etc. to the next speaker log module, and the speaker log module modifies and updates the broadcast task record, and then the execution subject calls the speaker scheduling module to send the message data Format it into a data format that can be more parsed by the lead, and push the broadcast message to the broadcast message receiving topic ③, the push quality QOS=0, offline message retention retail=true, set the offline message retention time, etc. Push the broadcast message to the speaker based on the MQTT protocol. The speaker performs the broadcast of the broadcast message, and pushes the broadcast message processing result to the message processing result topic ②, push quality QOS=2, keep offline messages retail=false, and broadcast the message through the MQTT protocol The processing result is pushed to the speaker scheduling module, and the speaker scheduling module parses the message processing result message, obtains the broadcast task message number, processing result status, and failure description information field value, and sends the broadcast task message number, processing result status, and failure description information to To the speaker log module, the speaker log module performs the updating of the broadcast message processing result. The whole process adopts Kafka distributed message queue to pin the peak of concurrent requests, redis memory database, and caches commonly used data to reduce the pressure on the database.

Fig. 4 is a schematic diagram of a system architecture of a message processing method according to an embodiment of the present application. Keep a persistent connection between the cloud broadcast device and the system service. Publish/subscribe mode: Based on an event channel, the object that takes over the notification subscribes to the subject through a custom event, and the object that is activated events notifies the subscribers of the subject object by publishing the subject event. Subscription and publication of messages can realize a one-to-one relationship between publishers and subscribers. The display layer provides the system function operation and maintenance interface of mobile terminal h5 and PC, which is convenient for merchants, operation and maintenance personnel to query, and device binding/unbinding operations. Service layer-external hardware device printer/audio: used to maintain a long connection between the cloud broadcast device and the MQTT service. Service layer-cloud broadcast device information management module: it is a module for binding/unbinding merchant and device information. Service layer-cloud broadcast device scheduling module: message subscription and publishing. Service layer-cloud broadcast device log management module: monitoring of message push, including total number of messages, number of successes, number of failures and success rate. Service layer-cloud broadcast device report statistics module: report statistics on messages. Persistence layer: MYSQL and Redis are used for persistent storage of data.

In the embodiment of this application, after the cloud broadcast device management service system is online, it provides MQTT connection service for the cloud broadcast device, publishes and subscribes topics, pushes broadcast messages, monitors the returned results, and implements a message resending mechanism for broadcast failure messages. Finally generate the report. For example, the user starts the message broadcast project through the cloud broadcast device management service system, connects to MQTT, and sends the user name username, password password, client ClientId, heartbeat time keepAlive, and connection timeout timeout to MQTT for connection. After receiving MQTT After the successful connection information is returned, subscribe to the MQTT system's own equipment offline topic (update the online status of the speaker, the topic mode is a wildcard, and monitor the online and offline) ①, subscribe to the broadcast task message processing result topic (update the broadcast result status, The topic mode is a wildcard)②, and start the scheduled task of generating asymmetric encryption key pairs after the subscription is successful, and check whether the key pairs in redis are less than 3000 pairs every 3 minutes, and if they are less than 3000 pairs, generate 5000 pairs of secret keys Supplement the quantity to prepare for the batch import of cloud broadcast devices; store the manufacturer whitelist information in redis to prepare for binding cloud broadcast devices and encrypting cloud broadcast devices to connect MQTT user information and data transmission encryption and decryption public keys. And monitor the MQTT push of the speaker's online message, obtain the corresponding speaker client ClienID (speaker SN number) and send it to the speaker binding information management module, and the speaker binding information management module will update the speaker's online status, update the speaker's status to the online status and turn the speaker The online status is stored in redis, and then the execution subject can call the cloud broadcast device management service system to create and subscribe to the topic of receiving broadcast messages for the speakers③, and push the payment information to receive the topic of receiving broadcast messages③ when receiving the payment information. Rules/terminalPublish/printOrVoice/device SN number/device type number. And MQTT pushes the payment information to the specific speaker, listens to the feedback message ② after the speaker broadcasts, parses the feedback message message, obtains the message number, message processing status, failure processing description field value and sends it to the speaker scheduling module to update the broadcast task according to the message number Processing status, failure sorting description, etc.

In the embodiment of this application, after the cloud broadcast device is online, the cloud broadcast device is registered successfully, automatically connects to the MQTT service when it is turned on, and automatically publishes/subscribes messages after completing the password verification. According to the payment success message, it is pushed to the device connected to MQTT. For example, the speaker binding information management module obtains MQTT user authentication information, data transmission encryption and decryption public key according to the speaker SN number, and sends the MQTT user authentication information, data transmission encryption and decryption public key ciphertext, the speaker is connected to MQTT, and MQTT performs user authentication. Information authentication, topic read and write permission verification, and store the results in the MYSQL database. MQTT push device online subject ①Push the speaker online message to the cloud broadcast device management service system, and the cloud broadcast device management service system sends the client ClientID (speaker SN number) to the speaker binding information management module, which is updated by the speaker binding information management module The speaker is online, and the updated online status of the speaker is saved to the redis database. The cloud broadcast device management service system creates and subscribes to the subject of receiving broadcast messages for the speakers ③, pushes the test message to the broadcast task receiving topic ③, and MQTT pushes the test message to the specific speaker. If the first data received is transaction data, the transaction data will be broadcast.

The embodiment of the present application uses the message queue remote sensing transmission protocol, which replaces the http protocol as an instant messaging protocol with low overhead and low bandwidth occupation, and greatly reduces the hardware cost requirements of the speaker and printer equipment. The interface protocols and specifications are unified within the industry, and manufacturers are responsible for adaptation, which reduces the development of equipment docking between different manufacturers. Services do not depend on equipment manufacturers, but manufacturers rely on in-line services. The embodiment of this application protects the security of the payment transaction data, and does not use the manufacturer's cloud service. The data does not need to be sent to the manufacturer's back-end service, but the cloud service is established in the industry, and the data is pushed to the stereo and printer. It overcomes the high performance requirements of the traditional http protocol on hardware equipment, and can use relatively cheap equipment to reduce costs. Interface protocols and specifications are formulated uniformly, and manufacturers adapt in-line services without relying on manufacturer interface protocols and specifications.

Fig. 5 is a schematic diagram of main units of a message processing device according to an embodiment of the present application. As shown in FIG. 5 , the message processing apparatus 500 includes an acquisition unit 501 , a device determination unit 502 , a task generation unit 503 and an execution unit 504 .

The obtaining unit 501 is configured to, in response to detecting payment transaction data, obtain a corresponding user ID and terminal ID, and then generate a broadcast message.

The device determining unit 502 is configured to determine a target cloud broadcast device based on the user identifier and the terminal identifier.

The task generation unit 503 is configured to acquire the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online.

The execution unit 504 is configured to call the target cloud broadcast device to execute the broadcast task, and in response to detecting a network anomaly when executing the broadcast task, call the connection service to repair the network anomaly and re-execute the broadcast task until the execution is successful, and output the broadcast result information.

In some embodiments, the obtaining unit 501 is further configured to: call the distributed message queue to determine the target consumption partition from the corresponding consumption partition set; call the target consumption partition to generate a broadcast message based on the user ID and the terminal ID.

In some embodiments, the device determining unit 502 is further configured to: determine the cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and the terminal identifier; obtain the cloud broadcast device corresponding to the one or more device identifiers The number of unexecuted broadcast tasks; based on the number of unexecuted broadcast tasks, determine the target cloud broadcast device.

In some embodiments, the device determining unit 502 is further configured to: sort the number of unexecuted broadcast tasks in ascending order; determine the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first as the target cloud broadcast device.

In some embodiments, the execution unit 504 is further configured to: in response to the current time reaching the preset execution time corresponding to the broadcast task, format the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device; The broadcast device broadcasts the message that the target cloud broadcast device can parse; outputs a message processing result message.

In some embodiments, the execution unit 504 is further configured to: parse the message processing result message to obtain the broadcast task message number, processing result status and failure description information field value; based on the broadcast task message number, processing result status and failure description The information field value updates the target cloud broadcast device log.

In some embodiments, the message processing apparatus further includes a status update unit not shown in FIG. 5, configured to: in response to the broadcast task being the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, the update status is offline.

It should be noted that the message processing method and the message processing device of the present application have a corresponding relationship in specific implementation content, so repeated content will not be described again.

Fig. 6 shows an exemplary system architecture 600 to which the message processing method or message processing device of the embodiment of the present application can be applied.

As shown in FIG. 6 , a system architecture 600 may include terminal devices 601 , 602 , and 603 , a network 604 and a server 605 . The network 604 is used as a medium for providing communication links between the terminal devices 601 , 602 , 603 and the server 605 . Network 604 may include various connection types, such as wires, wireless communication links, or fiber optic cables, among others.

Users can use terminal devices 601 , 602 , 603 to interact with server 605 via network 604 to receive or send messages and the like. Various communication client applications can be installed on the terminal devices 601, 602, 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (just for example).

The terminal devices 601, 602, 603 may be various electronic devices with message processing screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

The server 605 may be a server that provides various services, such as a background management server that provides support for payment transaction data detected by users using terminal devices 601 , 602 , 603 (just an example). The background management server can respond to the detection of payment transaction data, obtain the corresponding user ID and terminal ID, and then generate a broadcast message; based on the user ID and terminal ID, determine the target cloud broadcast device; obtain the status of the target cloud broadcast device, respond to the status To be online, generate a broadcast task based on the broadcast message; call the target cloud broadcast device to perform the broadcast task, and in response to detecting that the network is abnormal when performing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until the execution is successful , output broadcast result information. Relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

It should be noted that the message processing method provided in the embodiment of the present application is generally executed by the server 605 , and correspondingly, the message processing device is generally set in the server 605 .

It should be understood that the numbers of terminal devices, networks and servers in FIG. 6 are only illustrative. According to the implementation needs, there can be any number of terminal devices, networks and servers.

Referring now to FIG. 7 , it shows a schematic structural diagram of a computer system 700 suitable for implementing a terminal device according to an embodiment of the present application. The terminal device shown in FIG. 7 is only an example, and should not limit the functions and scope of use of this embodiment of the present application.

As shown in FIG. 7 , a computer system 700 includes a central processing unit (CPU) 701 that can operate according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage section 708 into a random-access memory (RAM) 703 Instead, various appropriate actions and processes are performed. In the RAM 703, various programs and data necessary for the operation of the computer system 700 are also stored. The CPU 701 , ROM 702 , and RAM 703 are connected to each other via a bus 704 . An input/output (I/O) interface 705 is also connected to the bus 704 .

The following components are connected to the I/O interface 705: an input part 706 including a keyboard, a mouse, etc.; an output part 707 including a cathode ray tube (CRT), a liquid crystal credit investigation authorization query processor (LCD) etc., and a speaker; including a hard disk etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc. is mounted on the drive 710 as necessary so that a computer program read therefrom is installed into the storage section 708 as necessary.

In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product, which includes a computer program carried on a computer-readable medium, where the computer program includes program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication portion 709 and/or installed from removable media 711 . When this computer program is executed by a central processing unit (CPU) 701, the above-mentioned functions defined in the system of the present application are performed.

It should be noted that the computer-readable medium shown in this application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. A computer-readable storage medium, for example, may include, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable Programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, in which computer-readable program codes are carried. Such propagated data signals may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. . Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or portion of code that includes one or more logical functions for implementing specified executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or they may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block in the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a A combination of dedicated hardware and computer instructions.

The units involved in the embodiments described in the present application may be implemented by means of software or by means of hardware. The described units may also be set in a processor. For example, it may be described as: a processor includes an acquisition unit, a device determination unit, a task generation unit, and an execution unit. Wherein, the names of these units do not constitute a limitation of the unit itself under certain circumstances.

As another aspect, the present application also provides a computer-readable medium. The computer-readable medium may be contained in the device described in the above embodiments, or may exist independently without being assembled into the device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by the device, the device responds to the detection of payment transaction data, acquires the corresponding user ID and terminal ID, and then generates a broadcast message; based on the user ID and the terminal ID, determine the target cloud broadcast device; acquire the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online; call the target cloud broadcast device to execute the broadcast task, and respond to the detected When the broadcast task is executed, the network is abnormal, and the connection service is called to repair the network abnormality, and the broadcast task is re-executed until the execution is successful, and the broadcast result information is output.

The computer program product of the present application includes a computer program, and when the computer program is executed by a processor, the message processing method in the embodiment of the present application is implemented.

According to the technical solutions of the embodiments of the present application, relatively cheap equipment can be used to reduce costs. For task execution exceptions caused by unstable networks, task execution can be resumed without trace, improving the success rate of task execution, and does not need to rely on vendor interface protocols and specifications, improving message processing efficiency and ensuring message processing timeliness.

The above specific implementation methods are not intended to limit the protection scope of the present application. It should be apparent to those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims (16)

1. A message processing method, characterized in that, comprising: In response to detecting the payment transaction data, obtain the corresponding user ID and terminal ID, and then generate a broadcast message; Determining a target cloud broadcast device based on the user identifier and the terminal identifier; Obtain the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online; Invoking the target cloud broadcast device to execute the broadcast task, in response to detecting a network anomaly during execution of the broadcast task, invoking the connection service to repair the network anomaly and re-executing the broadcast task until the execution is successful, outputting broadcast result information. 2. The method according to claim 1, wherein said generating a broadcast message comprises: Call the distributed message queue to determine the target consumption partition from the corresponding consumption partition set; Invoking the target consumption partition to generate a broadcast message based on the user identifier and the terminal identifier. 3. The method according to claim 1, wherein said determining the target cloud broadcast device comprises: determining a cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and the terminal identifier; Obtain the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to the one or more device identifiers; Based on the number of unexecuted broadcast tasks, a target cloud broadcast device is determined. 4. The method according to claim 3, wherein, determining the target cloud broadcast device based on the number of unexecuted broadcast tasks includes: Sorting the number of unexecuted broadcast tasks in ascending order; The cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first is determined as the target cloud broadcast device. 5. The method according to claim 1, wherein the calling the target cloud broadcast device to perform the broadcast task comprises: In response to the current time reaching the preset execution time corresponding to the broadcast task, formatting the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device; calling the target cloud broadcast device to broadcast the parseable message of the target cloud broadcast device; Output the message processing result message. 6. The method according to claim 5, characterized in that, after the output message processing result message, the method further comprises: Parsing the message processing result message to obtain the broadcast task message number, processing result status and failure description information field value; The target cloud broadcast device log is updated based on the broadcast task message number, processing result status, and failure description field value. 7. The method according to claim 1, characterized in that, when the network abnormality is detected in response to the execution of the broadcast task, the connection service is called to repair the network abnormality and the broadcast task is re-executed until the execution is successful, and the output After broadcasting the result information, the method also includes: In response to the broadcast task being the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, update the status to be offline. 8. A message processing device, comprising: The obtaining unit is configured to obtain the corresponding user identification and terminal identification in response to the detection of the payment transaction data, and then generate a broadcast message; A device determining unit configured to determine a target cloud broadcast device based on the user identifier and the terminal identifier; A task generation unit configured to acquire the status of the target cloud broadcast device, and generate a broadcast task based on the broadcast message in response to the status being online; The execution unit is configured to call the target cloud broadcast device to execute the broadcast task, and in response to detecting a network anomaly when executing the broadcast task, call the connection service to repair the network anomaly and re-execute the broadcast task until the execution is successful , output broadcast result information. 9. The device according to claim 8, wherein the acquiring unit is further configured to: Call the distributed message queue to determine the target consumption partition from the corresponding consumption partition set; Invoking the target consumption partition to generate a broadcast message based on the user identifier and the terminal identifier. 10. The apparatus according to claim 8, wherein the device determining unit is further configured to: determining a cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and the terminal identifier; Obtain the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to the one or more device identifiers; Based on the number of unexecuted broadcast tasks, a target cloud broadcast device is determined. 11. The apparatus according to claim 10, wherein the device determining unit is further configured to: Sorting the number of unexecuted broadcast tasks in ascending order; The cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first is determined as the target cloud broadcast device. 12. The device according to claim 8, wherein the execution unit is further configured to: In response to the current time reaching the preset execution time corresponding to the broadcast task, formatting the message message corresponding to the broadcast task into a message that can be parsed by the target cloud broadcast device; calling the target cloud broadcast device to broadcast the parseable message of the target cloud broadcast device; Output the message processing result message. 13. The device according to claim 12, wherein the execution unit is further configured to: Parsing the message processing result message to obtain the broadcast task message number, processing result status and failure description information field value; The target cloud broadcast device log is updated based on the broadcast task message number, processing result status, and failure description field value. 14. A message processing electronic device, characterized in that it comprises: one or more processors; storage means for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are made to implement the method according to any one of claims 1-7. 15. A computer-readable medium, on which a computer program is stored, wherein when the program is executed by a processor, the method according to any one of claims 1-7 is implemented. 16. A computer program product, comprising a computer program, characterized in that, when the computer program is executed by a processor, the method according to any one of claims 1-7 is implemented.

Images