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

By generating broadcast messages and fixing exceptions when network exceptions are made to re-execute tasks, the problems of high task failure rate and untimely message processing caused by unstable networks in mobile payments are solved, and efficient message processing is achieved.

CN115988058BActive Publication Date: 2025-07-04CHINA CONSTRUCTION BANK +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202310001639.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-01-03
Publication Date
2025-07-04
Estimated Expiration
2043-01-03

AI Technical Summary

Technical Problem

Unstable networks in mobile payments lead to high task execution failure rates, untimely message processing and inefficient efficiency.

Method used

Generate broadcast messages by obtaining user and terminal identifiers, determine the target cloud broadcast device, and call the connection service in case of network exceptions to fix the exception to re-execute the broadcast task until successful.

Benefits of technology

It improves the success rate of task execution, reduces costs, improves message processing efficiency, and ensures message processing timeliness.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115988058B_ABST
    Figure CN115988058B_ABST
Patent Text Reader

Abstract

The present application discloses a message processing method, apparatus, electronic device, and computer-readable medium, which relate to the technical field of the Internet of Things, and particularly to the technical field of networks and communications. A specific implementation manner includes: in response to detecting payment transaction data, obtaining the corresponding user identifier and terminal identifier, and then generating a broadcast message; determining a target cloud broadcast device based on the user identifier and terminal identifier; obtaining the status of the target cloud broadcast device, and in response to the status being online, generating a broadcast task based on the broadcast message; invoking the target cloud broadcast device to execute the broadcast task, and in response to detecting a network exception when executing the broadcast task, invoking a connection service to repair the network exception and re-execute the broadcast task until the execution is successful, and outputting broadcast result information. Relatively inexpensive devices can be used to reduce costs. The success rate of task execution is improved, the message processing efficiency is improved, and the message processing timeliness is ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of Internet of Things technology, particularly to the field of network and communication technology, and more particularly to a message processing method, apparatus, electronic device, and computer-readable medium. Background Art

[0002] Mobile payment has been widely popularized in recent years and has now become the main daily payment method for many consumers. Mobile payment mainly includes QR code payment, contactless payment, and payment by jumping to a third-party client. For an unstable network, it is impossible to natively recover from a disconnection failure, resulting in a high task execution failure rate. Moreover, after the user's payment is successful, the seller cannot be quickly notified in a timely manner, resulting in untimely and inefficient message processing. Summary of the Invention

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

[0004] To achieve the above object, according to one aspect of the embodiments of this application, a message processing method is provided, including:

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

[0006] Based on the user identifier and terminal identifier, determine the target cloud broadcast device;

[0007] Obtain the status of the target cloud broadcast device. In response to the status being online, generate a broadcast task based on the broadcast message;

[0008] Call the target cloud broadcast device to execute the broadcast task. In response to detecting a network exception when executing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed, and output the broadcast result information.

[0009] Optionally, generating the broadcast message includes:

[0010] Call the distributed message queue to determine the target consumption partition from the corresponding set of consumption partitions;

[0011] Call the target consumption partition to generate a broadcast message based on the user identifier and terminal identifier.

[0012] Optionally, determining the target cloud broadcast device includes:

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

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

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

[0016] Optionally, determining the target cloud broadcast device based on the number of unexecuted broadcast tasks includes:

[0017] Perform an ascending sort on the number of unexecuted broadcast tasks;

[0018] Determine the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first as the target cloud broadcast device.

[0019] Optionally, invoking the target cloud broadcast device to execute the broadcast task includes:

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

[0021] Invoke the target cloud broadcast device to broadcast the message that can be parsed by the target cloud broadcast device;

[0022] Output the message processing result report.

[0023] Optionally, after outputting the message processing result report, the method further includes:

[0024] Parse the message processing result report to obtain the broadcast task message number, processing result status, and the value of the failure description information field;

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

[0026] Optionally, after, in response to detecting a network exception during the execution of the broadcast task, invoking the connection service to repair the network exception and re-execute the broadcast task until the execution is successful and outputting the broadcast result information, the method further includes:

[0027] 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 offline.

[0028] In addition, the present application further provides a message processing device, including:

[0029] An obtaining unit, configured to, in response to detecting payment transaction data, obtain the corresponding user identifier and terminal identifier, and then generate a broadcast message;

[0030] A device determination unit, configured to determine the target cloud broadcast device based on the user identifier and terminal identifier;

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

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

[0033] Optionally, the obtaining unit is further configured to:

[0034] Call a distributed message queue to determine a target consumption partition from a corresponding set of consumption partitions;

[0035] Call the target consumption partition to generate a broadcast message based on a user identifier and a terminal identifier.

[0036] Optionally, the device determination unit is further configured to:

[0037] Determine a cloud broadcast device corresponding to one or more device identifiers bound to a user identifier and a terminal identifier;

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

[0039] Based on the number of unexecuted broadcast tasks, determine the target cloud broadcast device.

[0040] Optionally, the device determination unit is further configured to:

[0041] Perform an ascending sort on the number of unexecuted broadcast tasks;

[0042] Determine the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first as the target cloud broadcast device.

[0043] Optionally, the execution unit is further configured to:

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

[0045] Call the target cloud broadcast device to broadcast the message that can be parsed by the target cloud broadcast device;

[0046] Output a message processing result message.

[0047] Optionally, the execution unit is further configured to:

[0048] Parse the message processing result message to obtain the broadcast task message number, the processing result status, and the field value of the failure description information;

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

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

[0051] 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 offline.

[0052] 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, enabling the one or more processors to implement the message processing method as described above.

[0053] 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, it implements the message processing method as described above.

[0054] To achieve the above object, according to another aspect of the embodiments of the present application, a computer program product is provided.

[0055] A computer program product of the embodiments of the present application includes a computer program, and when the program is executed by a processor, it implements the message processing method provided by the embodiments of the present application.

[0056] One embodiment of the above invention has the following advantages or beneficial effects: By responding to the detection of payment transaction data, the present application obtains the corresponding user identification and terminal identification, and then generates a broadcast message; based on the user identification and terminal identification, determines the target cloud broadcast device; obtains the status of the target cloud broadcast device, and in response to the status being online, generates a broadcast task based on the broadcast message; calls the target cloud broadcast device to execute the broadcast task, and in response to detecting a network exception when executing the broadcast task, calls the connection service to repair the network exception and re-execute the broadcast task until the execution is successful, and outputs the broadcast result information. Relatively inexpensive devices can be used to reduce costs. For task execution exceptions caused by unstable networks, the task execution can be restored without a trace, improving the task execution success rate, and there is no need to rely on the manufacturer's interface protocol and specifications, improving the message processing efficiency and ensuring the message processing timeliness.

[0057] The further effects of the above non-conventional optional methods will be described in combination with specific embodiments below. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The accompanying drawings are used to better understand the present application and do not constitute an undue limitation on the present application. Among them:

[0059] Figure 1 is a schematic diagram of the main process of a message processing method according to an embodiment of the present application;

[0060] Figure 2 is a schematic diagram of the main process of a message processing method according to an embodiment of the present application;

[0061] Figure 3 is a schematic diagram of the main process of a message processing method according to an embodiment of the present application;

[0062] Figure 4 is a schematic diagram of the system architecture of a message processing method according to an embodiment of the present application;

[0063] Figure 5 is a schematic diagram of the main units of a message processing device according to an embodiment of the present application;

[0064] Figure 6 is an exemplary system architecture diagram to which an embodiment of the present application can be applied;

[0065] Figure 7 is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present application. Detailed Embodiments

[0066] The following describes exemplary embodiments of the present application with reference to the accompanying drawings. Various details of the embodiments of the present application are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted below. It should be noted that in the technical solutions of the present application, in terms of the collection, analysis, use, transmission, storage, etc. of user personal information, they all comply with the provisions of relevant laws and regulations, are used for legal and reasonable purposes, are not shared, leaked, or sold outside these legal uses, etc., and are subject to the supervision and management of regulatory authorities. Necessary measures should be taken for user personal information to prevent illegal access to such personal information data, ensure that personnel with the right to access personal information data comply with the provisions of relevant laws and regulations, and ensure the security of user personal information. Once these user personal information data are no longer needed, the risk should be minimized by restricting or even prohibiting data collection and / or deleting the data.

[0067] When in use, including in certain related applications, user privacy is protected by de-identifying data, such as by removing specific identifiers, controlling the amount or specificity of the data stored, controlling how the data is stored, and / or other de-identification methods when in use.

[0068] Figure 1 is a schematic diagram of the main process of a message processing method according to an embodiment of the present application, as Figure 1 shown, the message processing method includes:

[0069] Step S101, in response to detecting payment transaction data, obtain the corresponding user identifier and terminal identifier, and then generate a broadcast message.

[0070] In this embodiment, the execution entity of the message processing method (for example, it can be a server) can detect whether there is payment transaction data through a wired connection or a wireless connection. When detecting payment transaction data, the execution entity can obtain the corresponding user identifier. Specifically, the user identifier can be the account name or user name or merchant number of the user who triggers the generation of payment transaction data, etc., and the embodiments of the present application do not make specific limitations on the user identifier. The execution entity can also obtain the terminal identifier corresponding to the payment transaction data. For example, the terminal identifier can be the serial number (SN number) of the user's handheld terminal product or the Bluetooth address of the handheld terminal, etc., and the embodiments of the present application do not make specific limitations on the content and type of the terminal identifier. The execution entity can call a message generation program to generate a broadcast message according to the payment transaction data (for example, y yuan), the user identifier (for example, a), and the terminal identifier (for example, there is a payment transaction between c and the receiving terminal d). By way of example, the broadcast message can be "d received a payment of y yuan from a, please note for receipt".

[0071] Step S102, based on the user identifier and the terminal identifier, determine the target cloud broadcast device.

[0072] When the user identifier is the merchant number and the terminal identifier is the SN number of the merchant's mobile terminal. The execution entity can query the merchant-bound device information according to the user identifier and the terminal identifier. By way of example, the device can be a speaker for broadcasting information.

[0073] For example, merchant personnel can enter the system by scanning the QR code on the speaker base through the mobile H5 or through a link, and confirm whether the merchant and the device are bound by the merchant mobile SN number and the speaker SN number. Specifically, merchant personnel enter the message processing system by scanning the QR code on the speaker base through the mobile H5 or clicking on the link of the mobile H5 page. If the merchant personnel receive a prompt: Please scan the QR code on the base of the cloud broadcast device to enter the message processing system, they enter the message processing system by scanning the QR code according to the prompt, obtain the merchant number and the speaker SN number. The speaker binding information management module can call the merchant information query interface to query whether the transmitted merchant number exists. If it does not exist, it prompts that the merchant does not exist. If it exists, it continues to determine whether the speaker is bound by other merchants. If it is bound by other merchants, it prompts that the speaker has been bound by other merchants and jumps to the cloud broadcast device list page to display all the cloud broadcast devices that the transmitted merchant number can select for the merchant to choose from. If it is not bound by other merchants, it determines whether the speaker has been bound to the transmitted merchant number. If it has been bound to the transmitted merchant number, it jumps to the default query of the cloud broadcast device list to display the speaker corresponding to the sent speaker SN number (i.e., the target cloud broadcast device). If it has not been bound to the transmitted merchant number, it jumps to the cloud broadcast device binding page to bind the speaker corresponding to the speaker SN number.

[0074] It can be understood that if the user identifier corresponds to a unique terminal identifier, for example, when the merchant number has a unique handheld mobile phone SN number, the execution subject can simultaneously verify whether the speaker corresponding to the speaker SN number is bound based on the user identifier and the terminal identifier. For example, when the user identifier is bound to the speaker SN number, continue to verify whether the unique terminal identifier corresponding to the user identifier has also been bound to the speaker corresponding to the speaker SN number. This is more accurate than only verifying whether the speaker corresponding to the speaker SN number has been bound according to the user identifier (such as the merchant number). Among them, the acquisition method of the speaker SN number can include manual input or scanning code acquisition. For example, the merchant scans the QR code on the speaker base and jumps to the cloud broadcast device binding page to automatically bring out the speaker SN number. Further, the user identifier (such as the merchant number) can also be obtained by scanning the code on the code scanning login page and the terminal number (such as the terminal identifier) can be automatically brought out. And determine the target cloud broadcast device based on the user identifier and the terminal identifier, such as the target speaker for message broadcast.

[0075] Step S103, obtain the status of the target cloud broadcast device, and in response to the status being online, generate a broadcast task based on the broadcast message.

[0076] MQTT Protocol: The full name of MQTT (Message Queuing Telemetry Transport Protocol) is the abbreviation of Message Queuing Telemetry Transport Protocol. It is a message transmission protocol based on a lightweight broker's publish / subscribe model, running on top of the TCP protocol stack, providing an ordered, reliable, and two-way connected network connection guarantee. The target cloud broadcast device, such as the target speaker. After determining the target cloud broadcast device, the execution entity can obtain the status of the target cloud broadcast device, such as whether it has been bound to the current user, whether it has been bound to other users, etc. When binding to the current user, it prompts that the cloud broadcast device has been bound to the current cloud broadcast device. When not bound to the current user, it continues to determine whether the speaker is bound to other users. When bound to other users, it prompts that the cloud broadcast device has been bound to other users. When neither bound to the current user nor to other users, it obtains other candidate terminal identifiers corresponding to the user identifier, which can be obtained specifically through manual input or scanning a code. Furthermore, after obtaining the candidate terminal identifier, the execution entity can determine whether the terminal identifier on the binding page for binding the cloud broadcast device based on the candidate terminal identifier is added repeatedly. If so, it prompts not to repeat binding the terminal device. If not, it transmits the user identifier, candidate terminal identifier, speaker SN number, speaker name, and note information to the speaker binding information management module. Then, the speaker binding information management module sends the manufacturer number corresponding to the speaker SN number to the whitelist module to determine whether the manufacturer corresponding to the speaker SN number is in the whitelist. If not in the whitelist, it prompts the information that the cloud broadcast device has not been registered in the background. If in the whitelist, it saves the binding relationship between the speaker SN number, user identifier, and candidate terminal identifier, generates the MQTT user password, topic name, topic operation permission (readable and writable), encryption and decryption public and private keys for mutual message pushing of the cloud broadcast device corresponding to the speaker SN number, and saves them into 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.

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

[0078] Step S104, call the target cloud broadcast device to execute the broadcast task. In response to detecting a network exception when executing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed, and output the broadcast result information.

[0079] Each broadcast task can have a corresponding execution time, which can be real-time or at preset intervals.

[0080] 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 in the message format 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 in the message format corresponding to the broadcast task can be formatted into a data format that the speaker can better parse. Invoking the target cloud broadcast device to broadcast the message that can be parsed by the target cloud broadcast device. Specifically, it can be to push the message that can be parsed by the target cloud broadcast device (such as a message in a data format that the speaker can parse) to the broadcast message receiving topic for the corresponding speaker to consume the message in the subscribed broadcast message receiving topic; and then output the message processing result message.

[0081] MQTT protocol: MQTT (Message Queuing Telemetry Transport Protocol) is the abbreviation of the full name Message Queuing Telemetry Transport Protocol. It is a message transmission protocol based on the publish / subscribe mode of a lightweight broker, running on top of the TCP protocol stack, providing an ordered, reliable, and two-way connected network connection guarantee. When it is detected that the network is abnormal during the execution of the broadcast task, a connection service, such as an MQTT connection service, is invoked to repair the network anomaly and re-execute the broadcast task until the execution is successful, and the broadcast result information is output.

[0082] In this embodiment, by responding to the detection of payment transaction data, obtaining the corresponding user identifier and terminal identifier, and then generating a broadcast message; based on the user identifier and terminal identifier, determining the target cloud broadcast device; obtaining the status of the target cloud broadcast device, and in response to the status being online, generating a broadcast task based on the broadcast message; invoking the target cloud broadcast device to execute the broadcast task, and in response to detecting that the network is abnormal during the execution of the broadcast task, invoking a connection service to repair the network anomaly and re-execute the broadcast task until the execution is successful, and outputting the broadcast result information. Relatively inexpensive devices can be used to reduce costs. For task execution anomalies caused by an unstable network, the task execution can be restored without a trace, improving the task execution success rate, and not relying on the manufacturer's interface protocols and specifications, improving the message processing efficiency, and ensuring the message processing timeliness.

[0083] Figure 2 It is a schematic diagram of the main process of the message processing method according to an embodiment of the present application, as Figure 2 shown, the message processing method includes:

[0084] Step S201, in response to detecting payment transaction data, obtaining the corresponding user identifier and terminal identifier.

[0085] Payment transaction data can be, for example, transaction data generated when a user makes a payment for goods at a merchant.

[0086] The user identifier can be the merchant code, and the terminal identifier can be the serial number of the merchant terminal product (such as the SN number of the merchant POS machine).

[0087] Step S202: Invoke the distributed message queue to determine the target consumption partition from the corresponding set of consumption partitions.

[0088] The distributed message queue is, for example, Kafka. When Kafka saves messages, they are classified according to the topic. The message sender is called the Producer, and the message receiver is called the Consumer. In addition, the Kafka cluster consists of multiple Kafka instances, and each instance (server) is called a broker (i.e., the Kafka server). A topic contains multiple partitions, and each partition is a separate directory. By way of example, the partition naming rule is the topic + an ordered sequence number, for example, starting from zero to partition n - 1. In the embodiments of the present application, by way of example, Kafka can be configured with 30 partitions and one topic. The execution entity can call the consumer thread to randomly select a partition (or according to the specified partition) as the target consumption partition for message consumption.

[0089] Step S203: Invoke the target consumption partition to generate a broadcast message based on the user identifier and the terminal identifier.

[0090] Invoking the consumer thread to randomly select a partition as the target consumption partition for consumption can be to invoke the target consumption partition to obtain the payment transaction data and generate a broadcast message (such as "d has received a payment of y yuan from a, please check") based on the user identifier (such as a), the terminal identifier (such as there is a payment transaction between c and the receiving terminal d), and the payment transaction data (such as y).

[0091] Step S204: Determine the target cloud broadcast device based on the user identifier and the terminal identifier.

[0092] When the number of terminal identifiers corresponding to the user identifier is multiple, for example, 2 or more, the priority of the terminal identifier set by the user can be obtained, and then the candidate cloud broadcast device list can be determined according to the priority. Then, the execution entity can sequentially determine whether there is a cloud broadcast device already bound to the terminal identifier according to the priority. If the terminal identifier corresponding to the highest priority has a cloud broadcast device already bound, for example, cloud broadcast device Q, then the cloud broadcast device Q can be determined as the target cloud broadcast device. If the terminal identifier corresponding to the highest priority does not have a cloud broadcast device already bound, then the second highest priority is updated to the highest priority. If the terminal identifier corresponding to the second highest priority also does not have a cloud broadcast device already bound, then the second second highest priority is updated to the highest priority until the terminal identifier corresponding to the updated highest priority has a cloud broadcast device already bound.

[0093] Step S205, obtain the status of the target cloud broadcast device, and in response to the status being online, generate a broadcast task based on the broadcast message.

[0094] The status of the target cloud broadcast device, such as a speaker, can be in a bound and online state, a bound and offline state, an unbound and online state, an unbound and offline state, etc. The embodiments of the present application do not specifically limit the status of the target cloud broadcast device.

[0095] In response to the status of the target cloud broadcast device being in a bound and online state, a broadcast task is generated based on the broadcast message. The broadcast task can be a task executed synchronously or asynchronously. The embodiments of the present application do not specifically limit the type of the broadcast task.

[0096] Step S206, call the target cloud broadcast device to execute the broadcast task. In response to detecting a network exception when executing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed, and output the broadcast result information.

[0097] 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 exception when executing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed, and output the broadcast result information. For example, the broadcast result information can include the broadcast task message number, the processing result information, the failure description information, etc. The embodiments of the present application do not specifically limit the broadcast result information.

[0098] 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, the processing result status, and the failure description information field value; updating the target cloud broadcast device log based on the broadcast task message number, the processing result status, and the failure description information field value.

[0099] Embodiments of this application can use relatively inexpensive devices to reduce costs. For abnormal task execution caused by an unstable network, the task execution can be restored without a trace, improving the success rate of task execution. Moreover, it does not need to rely on the manufacturer's interface protocols and specifications, improving the message processing efficiency and ensuring the timeliness of message processing.

[0100] Figure 3 is a schematic diagram of the main process of a message processing method according to an embodiment of this application, as Figure 3 shown, the message processing method includes:

[0101] Step S301, in response to detecting payment transaction data, obtain the corresponding user identifier and terminal identifier.

[0102] The payment transaction data can be rental transaction data. The user identifier can be the name of the rental user corresponding to the rental transaction data, etc. The terminal identifier can be the serial number of the handheld terminal product corresponding to the rental user (such as the SN number).

[0103] Step S302, call the distributed message queue to determine the target consumption partition from the corresponding set of consumption partitions.

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

[0105] Step S303, call the target consumption partition to generate a broadcast message based on the user identifier and terminal identifier.

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

[0107] Step S304, determine the cloud broadcast device corresponding to one or more device identifiers bound to the user identifier and terminal identifier.

[0108] Step S305, obtain the number of unexecuted broadcast tasks in the cloud broadcast device corresponding to one or more device identifiers.

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

[0110] When one or more cloud broadcast devices are bound to the user identifier and terminal identifier, the target cloud broadcast device can be determined according to the number of pending broadcast tasks (that is, the number of unexecuted broadcast tasks) in the one or more cloud broadcast devices. For example, the cloud broadcast device with the least number of pending broadcast tasks among the bound devices can be determined as the target cloud broadcast device to improve the execution efficiency of the broadcast tasks.

[0111] Specifically, determining the target cloud broadcast device based on the number of unexecuted broadcast tasks includes: performing an ascending sort on the number of unexecuted broadcast tasks; determining the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first (i.e., the cloud broadcast device with the least number of unexecuted broadcast tasks) as the target cloud broadcast device.

[0112] Step S307: Obtain the status of the target cloud broadcast device. In response to the status being online, generate a broadcast task based on the broadcast message.

[0113] The number of target cloud broadcast devices can be one or multiple. When the number of target cloud broadcast devices is multiple, the execution entity can query the device information to determine the target cloud broadcast devices in the online state, and generate a broadcast task based on the broadcast message based on the SN numbers of the target cloud broadcast devices in the online state. Adding the SN number to the broadcast task can make the execution device of the broadcast task clearer and avoid the situation of chaotic device task execution.

[0114] When querying the device information, for example, the merchant can query the cloud broadcast device list through the mobile H5 page, query the information bound to the device according to the speaker SN number, and then determine the device status. For example, the merchant clicks on a certain speaker on the mobile H5 cloud broadcast device list page, obtains the speaker SN number, and sends the speaker SN number 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 jumps to the cloud broadcast device list page. If so, it queries the speaker details information based on the speaker SN number, and displays the speaker details information (such as the speaker name, speaker SN number, whether the speaker status is online or offline), as well as the merchant number, remarks, and terminal number on the mobile H5 cloud broadcast device details page.

[0115] Step S308: Invoke the target cloud broadcast device to execute the broadcast task. In response to detecting a network exception when executing the broadcast task, invoke the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed, and output the broadcast result information.

[0116] Specifically, after, in response to detecting a network exception when executing the broadcast task, invoking the connection service to repair the network exception and re-execute the broadcast task until it is successfully executed and outputting the broadcast result information, the message processing 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, updating the status to offline.

[0117] For example, after the cloud broadcast device shuts down and goes offline, the offline entity is pushed, and the cloud broadcast device is updated to the offline state, that is, the offline status. For example, the cloud broadcast device is a speaker. When the speaker is disconnected, the speaker offline message is pushed to the device offline topic ① through the Message Queuing Telemetry Transport Protocol (MQTT protocol). The cloud broadcast device management service system obtains the client ClientId and the speaker SN number and sends them to the speaker binding information management module. The speaker binding information management module updates the speaker to the offline state and saves the updated offline state of the speaker to the redis database.

[0118] The embodiments of the present application can use relatively inexpensive devices to reduce costs. For the abnormal task execution caused by an unstable network, the task execution can be restored without a trace, improving the task execution success rate. Moreover, it does not need to rely on the manufacturer's interface protocol and specifications, improving the message processing efficiency and ensuring the message processing timeliness.

[0119] In one embodiment of the present application, after a consumer makes a scan code payment, all payment transaction data is pushed through a push module. The transaction data includes a merchant number, a terminal number (such as a POS machine number, a counter number, etc.). Since the amount of data is relatively large, it is divided into 30 partitions through a Kafka message queue. The consumer thread randomly selects a partition for consumption and completes the message push according to whether the merchant is bound to a 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 the terminal number, and sends the merchant number and the terminal number to the speaker information binding module to obtain the binding information of the merchant, the merchant terminal and the speaker based on the merchant number and the terminal number, and stores it in the Redis database. After the cloud broadcast device (such as a speaker) is bound to the merchant, it can be bound by selecting a payment terminal under the merchant name for the push of the broadcast message. During the binding process, it is also necessary to verify whether the terminal number is added repeatedly to ensure the accuracy of the message push. The speaker information binding module filters and judges whether the merchant and the merchant terminal are bound to a speaker. If not, the broadcast message is not pushed. If so, it continues to judge whether the speaker is online. If it is not online, the broadcast message is not pushed. If it is online, the execution entity calls the speaker scheduling module to send information such as the global serial number, the merchant number, the order number, the speaker SN number, the data source, etc. to the following speaker log module. The speaker log module modifies the broadcast task record and updates it. Then, the execution entity calls the speaker scheduling module to format the message data into a data format that can be more easily parsed by the lead, and pushes the broadcast message to the broadcast message receiving topic ③. The push quality QOS = 0, the offline message retention retail = true, and the offline message retention time is set, etc. The broadcast message is pushed to the speaker based on the MQTT protocol. The speaker executes the broadcast of the broadcast message and pushes the processing result of the broadcast message to the message processing result topic ②. The push quality QOS = 2, the offline message retention retail = false, and the processing result of the broadcast message is pushed to the speaker scheduling module through the MQTT protocol. The speaker scheduling module parses the message processing result message, obtains the broadcast task message number, the processing result status, and the failure description information field value, and sends the broadcast task message number, the processing result status, and the failure description information to the speaker log module. The speaker log module executes the update of the processing result of the broadcast message. The entire process uses a Kafka distributed message queue to peak-shave concurrent requests, and a Redis in-memory database to cache frequently used data and reduce the pressure on the database.

[0120] Figure 4It is a schematic diagram of the system architecture of the message processing method according to an embodiment of the present application. Keep a long connection between the cloud broadcast device and the system service. Publish / subscribe mode: Based on an event channel, the object receiving the notification subscribes to the custom event subject, and the object activating the event notifies the subscribers of the subject object by publishing the subject event. The subscription and publication of messages can achieve a one-to-one relationship between the publisher and the subscriber. The presentation layer provides the system function operation and maintenance interfaces for mobile h5 and PC, facilitating merchants and operation and maintenance personnel to query and perform device binding / unbinding operations. Service layer - external hardware devices printer / speaker: used to keep a long connection between the cloud broadcast device and the MQTT service. Service layer - cloud broadcast device information management module: is the merchant and device information binding / unbinding module. Service layer - cloud broadcast device scheduling module: message subscription and publication. Service layer - cloud broadcast device log management module: monitors the message push, including the total number of messages, the number of successes, the number of failures, and the success rate. Service layer - cloud broadcast device report statistics module: performs report statistics on messages. Persistent layer: MYSQL and Redis are used for persistent storage of data.

[0121] In the embodiment of the present application, after the cloud broadcast device management service system is online, it provides MQTT connection services for cloud broadcast devices, publishes and subscribes to topics, pushes broadcast messages, monitors return results, and executes a message resending mechanism for broadcast failure messages. Finally, a report is generated. For example, the user starts the message broadcast project through the cloud broadcast device management service system, connects to MQTT, sends the username username, password password, client ClienId, heartbeat time keepAlive, and connection timeout timeout to MQTT for connection, and after receiving the successful connection information returned by MQTT, subscribes to the MQTT system's built-in device online and offline topics (updates the speaker online status, the topic mode is a wildcard, and monitors online and offline at the same time) ①, subscribes to the broadcast task message processing result topic (updates the broadcast result status, the topic mode is a wildcard) ②, and starts the scheduled task of generating asymmetric encryption key pairs after the subscription is successful. Every 3 minutes, check whether the key pairs in redis are less than 3000 pairs. If less than 3000 pairs, generate 5000 pairs of keys to supplement the number, in preparation for the batch import of cloud broadcast devices; store the manufacturer's whitelist information in redis to prepare for binding cloud broadcast devices and encrypting and issuing cloud broadcast devices to connect to MQTT user information and data transmission encryption and decryption public keys. And monitor the MQTT push of the speaker online message, obtain the corresponding speaker client ClientID (speaker SN number) and send it to the speaker binding information management module, and the speaker binding information management module updates the speaker online status, updates the speaker status to the online status and stores the speaker online status in redis, and then the execution subject can call the cloud broadcast device management service system to create and subscribe to the receiving broadcast message topic ③ for the speaker, and push the payment information to the receiving broadcast message receiving topic ③ when receiving the payment information issued, and the topic rule is / terminalPublish / printOrVoice / device SN number / device type number. And push the payment information to the specific speaker by MQTT, monitor the feedback message after the speaker broadcasts ②, parse the feedback message, obtain the message number, message processing status, and failure processing description field values ​​and send them to the speaker scheduling module to update the broadcast task processing status, failure combing description, etc. according to the message number.

[0122] In the embodiment of the present application, after the cloud broadcast device is launched, the cloud broadcast device is successfully registered, automatically connects to the MQTT service when powered on, and automatically publishes / subscribes messages after 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 the MQTT user authentication information and the data transmission encryption and decryption public key according to the speaker SN number, and issues the MQTT user authentication information and the ciphertext of the data transmission encryption and decryption public key. The speaker connects to MQTT, and MQTT performs user information authentication and topic read / write permission verification, and stores the results in the MYSQL database. MQTT pushes the device online main body ① to push the speaker online message to the cloud broadcast device management service system. The cloud broadcast device management service system sends the client ClientID (speaker SN number) to the speaker binding information management module, and the speaker binding information management module updates the speaker to the online state and saves the updated speaker online state to the redis database. The cloud broadcast device management service system creates and subscribes to the main body ③ for receiving broadcast messages for the speaker, pushes a test message to the broadcast task receiving topic ③, MQTT pushes the test message to the specific speaker. When the speaker successfully connects to the server, it broadcasts a voice reminder of successful connection to the service. If the first data received is transaction data, it broadcasts the transaction data.

[0123] The embodiment of the present application uses the Message Queuing Telemetry Transport protocol, which replaces the http protocol as an instant messaging protocol with low overhead and low bandwidth occupancy, greatly reducing the hardware cost requirements of the speaker printer device. The interface protocol and specification are uniformly built within the industry, and the manufacturer is responsible for adaptation, reducing the development of device docking for different manufacturers. The service does not depend on the device manufacturer, but the manufacturer depends on the in-industry service. The embodiment of the present application protects the security of payment transaction data. It does not adopt the manufacturer's cloud service. The data does not need to be sent to the manufacturer's backend service, but the in-industry establishes a cloud service, and the data is pushed to the speaker and printer. It overcomes the high performance requirements of the traditional http protocol for hardware devices, can use relatively inexpensive devices, and reduces costs. The interface protocol and specification are uniformly formulated, and the manufacturer adapts to the in-industry service, and does not need to depend on the manufacturer's interface protocol and specification.

[0124] Figure 5 It is a schematic diagram of the main unit of the message processing device according to the embodiment of the present application. As Figure 5 shown, the message processing device 500 includes an acquisition unit 501, a device determination unit 502, a task generation unit 503, and an execution unit 504.

[0125] The acquisition unit 501 is configured to, in response to detecting payment transaction data, acquire the corresponding user identifier and terminal identifier, and then generate a broadcast message.

[0126] The device determination unit 502 is configured to determine the target cloud broadcast device based on the user identifier and the terminal identifier.

[0127] A task generation unit 503 is configured to obtain the status of a target cloud broadcasting device, and in response to the status being online, generate a broadcasting task based on a broadcasting message.

[0128] An execution unit 504 is configured to call a target cloud broadcasting device to execute a broadcasting task. In response to detecting a network exception when executing the broadcasting task, call a connection service to repair the network exception and re-execute the broadcasting task until the execution is successful, and output broadcasting result information.

[0129] In some embodiments, the obtaining unit 501 is further configured to: call a distributed message queue to determine a target consumption partition from a corresponding set of consumption partitions; call the target consumption partition to generate a broadcasting message based on a user identifier and a terminal identifier.

[0130] In some embodiments, the device determination unit 502 is further configured to: determine a cloud broadcasting device corresponding to one or more device identifiers bound to a user identifier and a terminal identifier; obtain the number of unexecuted broadcasting tasks in the cloud broadcasting devices corresponding to the one or more device identifiers; and determine a target cloud broadcasting device based on the number of unexecuted broadcasting tasks.

[0131] In some embodiments, the device determination unit 502 is further configured to: perform an ascending sort on the number of unexecuted broadcasting tasks; and determine the cloud broadcasting device corresponding to the number of unexecuted broadcasting tasks ranked first as the target cloud broadcasting device.

[0132] In some embodiments, the execution unit 504 is further configured to: in response to the current time reaching a preset execution time corresponding to a broadcasting task, format a message of the broadcasting task into a message that can be parsed by the target cloud broadcasting device; call the target cloud broadcasting device to broadcast the message that can be parsed by the target cloud broadcasting device; and output a message processing result message.

[0133] In some embodiments, the execution unit 504 is further configured to: parse the message processing result message to obtain a message number of the broadcasting task, a processing result status, and a value of a failure description information field; and update a log of the target cloud broadcasting device based on the message number of the broadcasting task, the processing result status, and the value of the failure description information field.

[0134] In some embodiments, the message processing device further includes Figure 5 a status update unit (not shown in the figure), which is configured to: in response to the broadcasting task being the last broadcasting task in a broadcasting task list corresponding to the target cloud broadcasting device, update the status to offline.

[0135] It should be noted that there is a corresponding relationship between the message processing method and the message processing device of the present application in terms of specific implementation content, so the repeated content will not be described again.

[0136] Figure 6 Fig. 600 shows an exemplary system architecture to which the message processing method or message processing apparatus according to the embodiments of the present application can be applied.

[0137] As Figure 6 shown, the system architecture 600 may include terminal devices 601, 602, 603, a network 604, and a server 605. The network 604 is used to provide a medium for communication links between the terminal devices 601, 602, 603 and the server 605. The network 604 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0138] Users can use the terminal devices 601, 602, 603 to interact with the server 605 through the network 604 to receive or send messages, etc. Various communication client applications may 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. (only for example).

[0139] The terminal devices 601, 602, 603 may be various electronic devices having a message processing screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, and desktop computers, etc.

[0140] The server 605 may be a server providing various services, such as a background management server (only for example) that provides support for payment transaction data detected by users using the terminal devices 601, 602, 603. The background management server may, in response to detecting payment transaction data, obtain the corresponding user identifier and terminal identifier, and then generate a broadcast message; based on the user identifier and terminal identifier, determine the target cloud broadcast device; obtain the status of the target cloud broadcast device, and in response to the status being online, generate a broadcast task based on the broadcast message; call the target cloud broadcast device to execute the broadcast task, and in response to detecting a network exception when executing the broadcast task, call the connection service to repair the network exception and re-execute the broadcast task until the execution is successful, and output the broadcast result information. Relatively inexpensive devices can be used to reduce costs. For task execution exceptions caused by unstable networks, the task execution can be restored without a trace, improving the task execution success rate, and without relying on vendor interface protocols and specifications, improving the message processing efficiency and ensuring the message processing timeliness.

[0141] It should be noted that the message processing method provided by the embodiments of the present application is generally executed by the server 605. Correspondingly, the message processing apparatus is generally disposed in the server 605.

[0142] It should be understood that Figure 6The numbers of the terminal devices, networks, and servers in [it] are merely illustrative. According to the implementation requirements, there can be any number of terminal devices, networks, and servers.

[0143] Reference is made below to Figure 7 , which shows a schematic structural diagram of a computer system 700 of a terminal device suitable for implementing the embodiments of the present application. Figure 7 The terminal device shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0144] As Figure 7 shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 702 or the program loaded from the storage section 708 into the random access memory (RAM) 703. In the RAM 703, various programs and data required 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. The input / output (I / O) interface 705 is also connected to the bus 704.

[0145] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including such as a cathode ray tube (CRT), a liquid crystal credit authorization query processor (LCD), etc. and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, etc. 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, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that the computer program read from it can be installed into the storage section 708 as needed.

[0146] 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 the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, the above functions defined in the system of the present application are executed.

[0147] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of a computer-readable storage medium can include but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0148] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram can represent a module, a program segment, or a part of code, and the above-mentioned module, program segment, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks can occur in a different order than that marked in the accompanying drawings. For example, two consecutively represented blocks can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, as well as the combination of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system for performing the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0149] The units involved in the embodiments described in this application can be implemented in software or in hardware. The described units can also be provided in a processor. For example, it can be described as: A processor includes an acquisition unit, a device determination unit, a task generation unit, and an execution unit. Among them, the names of these units do not constitute a limitation on the unit itself in some cases.

[0150] As another aspect, this application also provides a computer-readable medium. This computer-readable medium can be included in the device described in the above embodiments; it can also exist alone without being assembled into the device. The above computer-readable medium carries one or more programs. When the above one or more programs are executed by the device, the device, in response to detecting payment transaction data, acquires the corresponding user identifier and terminal identifier, and then generates a broadcast message; based on the user identifier and terminal identifier, determines the target cloud broadcast device; acquires the status of the target cloud broadcast device, and in response to the status being online, generates a broadcast task based on the broadcast message; calls the target cloud broadcast device to execute the broadcast task, and in response to detecting a network exception when executing the broadcast task, calls a connection service to repair the network exception and re-execute the broadcast task until the execution is successful, and outputs broadcast result information.

[0151] The computer program product of this application includes a computer program that, when executed by a processor, implements the message processing method in the embodiments of this application.

[0152] According to the technical solution of the embodiments of this application, relatively inexpensive devices can be used to reduce costs. For abnormal task execution caused by an unstable network, the task execution can be restored without a trace, improving the success rate of task execution, and there is no need to rely on the manufacturer's interface protocols and specifications, improving the message processing efficiency and ensuring the message processing timeliness.

[0153] The above specific implementation manners do not constitute a limitation on the protection scope of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims

1. A message processing method, characterized in that, Including: Upon detecting payment transaction data, obtain the corresponding user identifier and terminal identifier, and then generate a broadcast message; Based on the user identifier and the terminal identifier, determine a target cloud broadcast device, including: determining cloud broadcast devices corresponding to one or more device identifiers bound to the user identifier and the terminal identifier; obtaining the number of unexecuted broadcast tasks in the cloud broadcast devices corresponding to the one or more device identifiers; based on the number of unexecuted broadcast tasks, determine the cloud broadcast device with the least number of unexecuted broadcast tasks as the target cloud broadcast device; Obtain the status of the target cloud broadcast device, and upon the status being online, generate a broadcast task based on the broadcast message; Invoke the target cloud broadcast device to execute the broadcast task. Upon detecting a network anomaly during the execution of the broadcast task, invoke a connection service to repair the network anomaly and re-execute the broadcast task until successful execution, and output broadcast result information.

2. The method according to claim 1, wherein The generating of the broadcast message includes: Invoke a distributed message queue to determine a target consumption partition from a corresponding set of consumption partitions; Invoke 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 The determining of the target cloud broadcast device based on the number of unexecuted broadcast tasks includes: Perform an ascending sort on the number of unexecuted broadcast tasks; Determine the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first as the target cloud broadcast device.

4. The method according to claim 1, wherein The invoking of the target cloud broadcast device to execute the broadcast task includes: Upon the current time reaching the preset execution time corresponding to the broadcast task, format the message of the broadcast task into a message that can be parsed by the target cloud broadcast device; Invoke the target cloud broadcast device to broadcast the message that can be parsed by the target cloud broadcast device; Output a message processing result message.

5. The method according to claim 4, wherein After the output of 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 the value of the failure description information field; Update the target cloud broadcast device log based on the broadcast task message number, processing result status, and the value of the failure description information field.

6. The method according to claim 1, wherein After the invoking of the connection service to repair the network anomaly and re-execute the broadcast task until successful execution and output of the broadcast result information upon detecting a network anomaly during the execution of the broadcast task, the method further includes: Upon the broadcast task being the last broadcast task in the broadcast task list corresponding to the target cloud broadcast device, update the status to offline.

7. A message processing device, characterized in that, Including: An obtaining unit configured to, upon detecting payment transaction data, obtain the corresponding user identifier and terminal identifier, and then generate a broadcast message; A device determination unit, configured to determine a target cloud broadcast device based on the user identifier and the terminal identifier, including: determining cloud broadcast devices corresponding to one or more device identifiers bound to the user identifier and the terminal identifier; obtaining the number of unexecuted broadcast tasks in the cloud broadcast devices corresponding to the one or more device identifiers; based on the number of unexecuted broadcast tasks, determining the cloud broadcast device with the least number of unexecuted broadcast tasks as the target cloud broadcast device; A task generation unit, configured to obtain the status of the target cloud broadcast device, and in response to the status being online, generate a broadcast task based on the broadcast message; An execution unit, configured to call the target cloud broadcast device to execute the broadcast task, and in response to detecting a network exception when executing the broadcast task, call a connection service to repair the network exception and re-execute the broadcast task until the execution is successful, and output broadcast result information.

8. The device according to claim 7, characterized in that, The obtaining unit is further configured to: Call a distributed message queue to determine a target consumption partition from a corresponding set of consumption partitions; Call the target consumption partition to generate a broadcast message based on the user identifier and the terminal identifier.

9. The device according to claim 7, characterized in that, The device determination unit is further configured to: Perform an ascending sort on the number of unexecuted broadcast tasks; Determine the cloud broadcast device corresponding to the number of unexecuted broadcast tasks ranked first as the target cloud broadcast device.

10. The device according to claim 7, characterized in that, The execution unit is further configured to: In response to the current time reaching the preset execution time corresponding to the broadcast task, format the message of 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 can be parsed by the target cloud broadcast device; Output a message processing result message.

11. The device according to claim 10, characterized in that, The execution unit is further configured to: Parse the message processing result message to obtain the broadcast task message number, the processing result status, and the value of the failure description information field; Update the target cloud broadcast device log based on the broadcast task message number, the processing result status, and the value of the failure description information field.

12. A message processing electronic device, characterized in that, 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, the one or more processors implement the method according to any one of claims 1-6.

13. A computer-readable medium having a computer program stored thereon, characterized in that, The program, when executed by the processor, implements the method according to any one of claims 1-6.

14. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the method according to any one of claims 1-6.

Citation Information

Patent Citations

  • Intelligent broadcast method and device

    CN107423974A

  • Message push method and message push device

    CN109428921A