Abnormal message processing method, device, equipment, medium and product

Abstract

The present application provides an exception message processing method, apparatus, equipment, medium and product, wherein the method includes obtaining type information of the exception message to be processed, whether it is an ordered message, whether there is a dependency relationship with other messages and whether it is recoverable, and determining the type of the exception message to be processed according to the type information of the exception message to be processed; the types include unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable. Based on the processing strategy corresponding to each type, the processing strategy corresponding to the type of the exception message to be processed is adopted to perform corresponding processing on the exception message. The solution of the present application can avoid message congestion and resource waste in the message queue and improve the efficiency of message processing.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a method, apparatus, device, medium, and product for processing abnormal messages. Background Art

[0002] As enterprises expand and user traffic increases, the performance requirements for inter-system message transmission become increasingly stringent. Producers send messages to be delivered to message queues, and consumers extract and process them from the message queues. However, in actual use, consumers often fail to process messages due to various reasons, resulting in message consumption failures.

[0003] The current approach to handling failed messages is for the consumer to continue consuming the message or to place the message into a retry topic, where the retry consumer continues to consume the message. However, this approach can easily cause message blocking and resource waste in high-concurrency scenarios, significantly reducing message processing efficiency. Summary of the Invention

[0004] The present application provides an abnormal message processing method, device, equipment, medium and product to improve message processing efficiency.

[0005] In one aspect, the present application provides a method for handling abnormal messages, the method comprising:

[0006] Obtain type information of the exception message to be processed, including whether it is an ordered message, whether it has dependencies with other messages, and whether it is recoverable;

[0007] Determine the type of the exception message to be processed according to the type information of the exception message to be processed; the types include unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable;

[0008] Based on the processing strategies corresponding to each type, the processing strategy corresponding to the type of the abnormal message to be processed is adopted to perform corresponding processing on the abnormal message.

[0009] In one embodiment, the processing strategy corresponding to each type is adopted based on the processing strategy corresponding to the type of the exception message to be processed, and the corresponding processing is performed on the exception message to be processed, including:

[0010] If the type of the pending exception message is out of order and unrecoverable, the pending exception message is pushed to the consumer user through the message sender for processing; and the message processor is instructed to process the message after the pending exception message in the message queue;

[0011] If the type of the pending exception message is out of order and recoverable, calling the retryer to process the pending exception message again; and instructing the message processor to process the message after the pending exception message in the message queue;

[0012] If the type of the pending exception message is ordered, independent, and irrecoverable, the pending exception message and a first message that has a sequence relationship with the pending exception message are pushed to the consumer user for processing through the message sender; and the message processor is instructed to process the pending exception message and the messages after the first message in the message queue;

[0013] If the type of the pending exception message is ordered, independent, and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor. If the processing fails, the latest message in the first message is obtained from the message queue for processing;

[0014] If the type of the pending exception message is ordered dependency and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue;

[0015] If the type of the pending exception message is ordered dependency and cannot be recovered, the pending exception message will be pushed to the consumer user through the message sender for processing. If the processing is successful, the success result will be returned to the message processor, and the message processor will be instructed to process the messages after the pending exception message in the message queue.

[0016] In one embodiment, if the type of the exception message to be processed is unordered and irrecoverable or ordered, independent of dependency and irrecoverable, then pushing the exception message to be processed to the consumer user through a message sender for processing includes:

[0017] Storing the to-be-processed exception message in an exception message storage;

[0018] If the message data in the current abnormal message storage reaches a set threshold, all messages in the abnormal message storage, including the abnormal message to be processed, are pushed to the consumer user through the message sender for processing.

[0019] In one embodiment, if a message in the abnormal message storage is pushed to a consuming user for processing, the message is deleted from the abnormal message storage.

[0020] In one embodiment, if the type of the pending exception message is unordered and recoverable or ordered dependent and recoverable, the calling retryer processes the pending exception message again, including:

[0021] If the type of the pending exception message is unordered and recoverable or ordered, dependent and recoverable, the retryer is called to process the pending exception message again until the processing is successful or until the pending exception message is repeatedly processed by the retrieval device for a set number of times reaches the set number threshold, and then it is pushed to the consumer user through the message sender for processing.

[0022] On the other hand, the present application provides an abnormal message processing device, the device comprising:

[0023] An acquisition module is used to obtain type information of the exception message to be processed, the type information including whether it is an ordered message, whether it has a dependency relationship with other messages, and whether it is recoverable;

[0024] a determination module, configured to determine the type of the exception message to be processed according to the type information of the exception message to be processed; the types including unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable;

[0025] The processing module is used to perform corresponding processing on the abnormal message based on the processing strategy corresponding to each type and adopting the processing strategy corresponding to the type of the abnormal message to be processed.

[0026] In one embodiment, the processing module is specifically configured to push the exception message to be processed to the consumer user through a message sender for processing if the type of the exception message to be processed is out of order and unrecoverable; and instruct the message processor to process the message after the exception message to be processed in the message queue;

[0027] The processing module is further configured to call a retryer to process the exception message to be processed again if the type of the exception message to be processed is out of order and recoverable; and instruct a message processor to process messages subsequent to the exception message to be processed in the message queue;

[0028] The processing module is further configured to, if the type of the to-be-processed exception message is ordered, independent of dependency, and irrecoverable, push the to-be-processed exception message and a first message that has a sequence relationship with the to-be-processed exception message to a consumer user for processing through a message sender; and instruct a message processor to process the to-be-processed exception message and messages subsequent to the first message in the message queue;

[0029] The processing module is further configured to, if the type of the to-be-processed exception message is ordered, independent of dependencies, and recoverable, call a retryer to process the to-be-processed exception message again; if the processing is successful, return a success result to the message processor; if the processing fails, obtain the latest message in the first message from the message queue for processing;

[0030] The processing module is further configured to, if the type of the to-be-processed exception message is an ordered dependency and recoverable, call a retryer to process the to-be-processed exception message again; if the processing is successful, return a success result to the message processor, and instruct the message processor to process the message after the to-be-processed exception message in the message queue;

[0031] The processing module is specifically used to push the pending exception message to the consumer user through the message sender for processing if the type of the pending exception message is ordered dependency and cannot be recovered. If the processing is successful, the success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue.

[0032] In yet another aspect, the present disclosure provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0033] The memory stores computer-executable instructions;

[0034] The processor executes the computer-executable instructions stored in the memory to implement the abnormal message processing method as described in any of the above items.

[0035] On the other hand, the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the abnormal message processing method as described in any of the above items.

[0036] On the other hand, the present disclosure provides a computer program product, including a computer program, which implements the abnormal message processing method as described in any of the above items when executed by a processor.

[0037] In the exception message processing method, device, equipment, medium and product provided by the present application, the exception messages to be processed are divided into six different types of exception messages: unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable, according to whether they are ordered messages, whether they have dependencies with other messages, and whether they are recoverable. Based on the processing strategies corresponding to each type, the processing strategy corresponding to the type of the exception message to be processed is adopted to perform corresponding processing on the exception message. The present application processes the exception message according to whether the exception message is an ordered message, whether it has dependencies with other messages, and whether it is recoverable, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0039] Figure 1 This is a schematic diagram of an application scenario for this application example;

[0040] Figure 2 A flowchart of a method for handling abnormal messages provided in Example 1 of the present application;

[0041] Figure 3 A schematic diagram of the structure of an abnormal message processing device provided in Example 2 of the present application;

[0042] Figure 4 Provide a structural diagram of an abnormal message processing system for application embodiment 3;

[0043] Figure 5 This is a schematic diagram of the rule configurator structure;

[0044] Figure 6 This is the workflow diagram of the retryer;

[0045] Figure 7 This is the overall workflow diagram of the exception message processing system;

[0046] Figure 8 Processing rules corresponding to out-of-order exception messages;

[0047] Figure 9 Processing rules for ordered, non-dependent exception messages;

[0048] Figure 10 Processing rules corresponding to ordered dependency exception messages;

[0049] Figure 11A schematic structural diagram of an electronic device provided in an embodiment of the present disclosure.

[0050] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0051] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0052] Figure 1 This is a schematic diagram of an application scenario for this application example, illustrating a schematic diagram of data communication between a producer, a message queue, and a consumer. The message queue is a container for storing messages, the producer is the producer of messages, and the consumer is the receiver of messages. The producer is responsible for sending the produced messages as messages to be delivered to the message queue, without worrying about whether the consumer correctly obtains and uses the delivered messages. The consumer pulls the messages to be delivered from the message queue and consumes them.

[0053] It should be noted that the brief descriptions of terms in this application are only for the purpose of facilitating the understanding of the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their ordinary and usual meanings.

[0054] The technical solutions of the present application and the technical solutions of the present application are described in detail below with reference to specific embodiments. The following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in certain embodiments. In the description of the present application, unless otherwise clearly specified and limited, each term should be understood in a broad sense within the art. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0055] Example 1

[0056] Figure 2 A flowchart of a method for handling abnormal messages provided in Example 1 of the present application is shown as follows: Figure 2 As shown, the method includes:

[0057] Step 201: Obtain type information of the exception message to be processed, including whether it is an ordered message, whether it has dependencies with other messages, and whether it is recoverable.

[0058] Step 202: Determine the type of the exception message to be processed according to the type information of the exception message to be processed; the types include unordered and unrecoverable, unordered and recoverable, ordered without dependency and unrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and unrecoverable;

[0059] Step 203: Based on the processing strategies corresponding to the types, the processing strategy corresponding to the type of the abnormal message to be processed is adopted to perform corresponding processing on the abnormal message.

[0060] According to the scenario example, when the consumer pulls the message to be delivered from the message queue for consumption processing, an exception message may appear due to certain errors. The exception message means that after the consumer obtains the message to be delivered, it is unable to perform subsequent consumption processing on the message to be delivered. The exception message itself does not have a problem, but is caused by certain errors of the consumer. When the consumer consumes the message to be delivered, there are many kinds of errors that cause the generation of exception messages, which leads to inconsistent error types of the generated exception messages. For example, when an error occurs in the program itself, the error type of the exception message generated is irrecoverable. An irrecoverable error refers to an error that cannot be automatically repaired without human intervention. Alternatively, when an external environment error such as network jitter occurs, the error type of the exception message generated is recoverable. A recoverable error refers to an error that can be automatically recovered after a period of time without human intervention.

[0061] In addition to recoverable and unrecoverable error types, the exception message itself also has the properties of ordered, unordered, dependent and non-dependent. The ordered nature of the message means that the order in which the consumer consumes and processes the messages is related to the order in which the producer generates data; the unordered nature of the message means that the order in which the consumer consumes and processes the messages has nothing to do with the order in which the producer generates data; the dependent nature of the message means that the message is ordered, and whether the message at the back can be successfully executed depends on the execution result of the message at the front; the non-dependent nature of the message means that the message is ordered, and whether the message at the back can be successfully executed does not depend on the execution result of the message at the front.

[0062] Combining the error type of the exception message and the classification of the nature of the message itself, the types of exception messages to be processed can be roughly divided into six categories, namely: unordered and unrecoverable, unordered and recoverable, ordered without dependencies and unrecoverable, ordered without dependencies and recoverable, ordered with dependencies and recoverable, and ordered with dependencies and unrecoverable. With respect to the six categories into which the exception messages to be processed are divided, a subsequent processing strategy is set for each type of exception data to be processed. The processing strategy set for the exception message to be processed is determined by the type of the exception message to be processed, and the processing of the exception message to be processed is completed according to the processing strategy corresponding to the exception message to be processed, and the processing result is returned to the consumer.

[0063] This example processes the exception message using a processing strategy suitable for the type of exception message based on whether the exception message is an ordered message, whether it has dependencies with other messages, and whether it is recoverable, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing. Each type of processing strategy processes the exception message, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of consumer message processing.

[0064] Optionally, the processing strategy corresponding to each type is adopted based on the processing strategy corresponding to the type of the exception message to be processed, and corresponding processing is performed on the exception message to be processed, including:

[0065] If the type of the pending exception message is out of order and unrecoverable, the pending exception message is pushed to the consumer user through the message sender for processing; and the message processor is instructed to process the message after the pending exception message in the message queue;

[0066] If the type of the pending exception message is out of order and recoverable, calling the retryer to process the pending exception message again; and instructing the message processor to process the message after the pending exception message in the message queue;

[0067] If the type of the pending exception message is ordered, independent, and irrecoverable, the pending exception message and a first message that has a sequence relationship with the pending exception message are pushed to the consumer user for processing through the message sender; and the message processor is instructed to process the pending exception message and the messages after the first message in the message queue;

[0068] If the type of the pending exception message is ordered, independent, and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor. If the processing fails, the latest message in the first message is obtained from the message queue for processing;

[0069] If the type of the pending exception message is ordered dependency and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue;

[0070] If the type of the pending exception message is ordered dependency and cannot be recovered, the pending exception message will be pushed to the consumer user through the message sender for processing. If the processing is successful, the success result will be returned to the message processor, and the message processor will be instructed to process the messages after the pending exception message in the message queue.

[0071] Combined with the scenario example, if the messages to be delivered in the message queue are out of order, and the consumer generates an unrecoverable error in the process of consuming the messages to be delivered, resulting in an unordered and unrecoverable exception message, based on the processing strategy corresponding to the unordered and unrecoverable exception message, it can be sent to the consumer user corresponding to the exception message through the message sender for manual processing. Since the messages to be delivered in the message queue are out of order, whether the exception message is successfully consumed and processed does not affect the continued consumption and processing of other messages to be delivered in the message queue. Therefore, after the message sender sends the unordered and unrecoverable exception message to the corresponding consumer user for manual processing, it can instruct the message processor at the consumer to continue consuming and processing the next message to be delivered after the exception message. The consumer includes a message processor, and the consumer realizes message consumption processing through the message processor.

[0072] If the pending messages in the message queue are out of order, and a recoverable error occurs during the consumer's consumption of the pending messages, resulting in an out-of-order and recoverable exception message, a retryer may be invoked based on the processing strategy corresponding to the out-of-order and recoverable exception message to re-consume the out-of-order and recoverable exception message. The retryer also includes a message processor, which re-consumes the out-of-order and recoverable exception message and instructs the consumer to continue consuming the next pending message in the message queue following the exception message.

[0073] If the messages to be delivered in the message queue are ordered and independent of dependencies, and the consumer generates an unrecoverable error during the consumption process of the messages to be delivered, resulting in an ordered, independent, and unrecoverable exception message, based on the processing strategy corresponding to the ordered, independent, and unrecoverable exception message, the ordered, independent, and unrecoverable exception message is sent to the corresponding consumer user through the message sender for manual processing. Since the messages to be delivered in the message queue are currently ordered, before the ordered, independent, and unrecoverable exception message is successfully consumed, the first message that has a sequence relationship with the ordered, independent, and unrecoverable exception message cannot be successfully consumed and processed by the consumer's message processor. The first message refers to other messages to be delivered that have a sequence relationship with the ordered, independent, and unrecoverable exception message. Therefore, based on the processing strategy corresponding to the ordered, independent, and unrecoverable exception message, the message sender sends the ordered, independent, and unrecoverable exception message to the corresponding consumer user for manual processing, and also sends the first message to the corresponding consumer user for manual processing. The consumer is instructed to continue consuming and processing the ordered, independent, and unrecoverable exception message and the messages to be transmitted after the first message.

[0074] If the messages to be delivered in the message queue are ordered and independent of dependencies, and a recoverable error occurs in the process of the consumer consuming the messages to be delivered, resulting in an ordered, independent, and recoverable exception message, the retrieval device is called to re-consume the ordered, independent, and recoverable exception message based on the processing strategy corresponding to the ordered, independent, and recoverable exception message. If the retrieval device successfully re-consumes and processes the ordered, independent, and recoverable exception message, the result is returned to the consumer, and the consumer will continue to consume and process the next message to be delivered. If the retrieval device fails to successfully re-consume and process the ordered, independent, and recoverable exception message, the retrieval device obtains the latest message in the first message that has a sequential relationship with the ordered, independent, and recoverable exception message from the message queue, and re-consumes and processes the latest message. The retrieval device also instructs the consumer to continue consuming and processing the ordered, independent, and recoverable exception message and the messages to be transmitted after the first message.

[0075] If the pending messages in the message queue are ordered-dependent, and a recoverable error occurs during the consumer's consumption of the pending messages, resulting in an ordered-dependent and recoverable exception message, the retrieval device is called to consume the ordered-dependent and recoverable exception message again based on the processing strategy corresponding to the ordered-dependent and recoverable exception message. Since the pending messages in the message queue are ordered-dependent, the consumer can only consume the subsequent pending messages after the exception message is successfully consumed, and the error type of the exception message is recoverable, so the retrieval device can be continuously called to consume the exception message.

[0076] If the messages to be delivered in the message queue are ordered-dependent, and the consumer generates an unrecoverable error in the process of consuming the messages to be delivered, resulting in an ordered-dependent and unrecoverable exception message, based on the processing strategy corresponding to the ordered-dependent and unrecoverable exception message, the order-dependent and unrecoverable exception message can be sent to the corresponding consumer user for consumption processing through the message sender. Similar to the ordered-dependent and recoverable exception message, the messages to be delivered in the message queue are ordered-dependent, so the consumer can only consume and process the subsequent messages to be delivered after the exception message is successfully consumed. However, the current exception message error type is unrecoverable, so the retryer cannot be called to repeatedly consume it. It can only be sent to the corresponding consumer user for consumption processing until the consumption of the exception message is completed.

[0077] This example processes the abnormal messages according to the processing strategy corresponding to each type, avoiding message congestion and resource waste in the message queue and improving the efficiency of consumer message processing.

[0078] Optionally, if the type of the exception message to be processed is unordered and irrecoverable or ordered, independent of dependency and irrecoverable, then pushing the exception message to be processed to the consumer user through the message sender for processing includes:

[0079] Storing the to-be-processed exception message in an exception message storage;

[0080] If the message data in the current abnormal message storage reaches a set threshold, all messages in the abnormal message storage, including the abnormal message to be processed, are pushed to the consumer user through the message sender for processing.

[0081] According to the scenario example, for the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message, before sending the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message to the corresponding consumer user for manual processing, the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message can be stored in a message storage. The message storage is responsible for storing and recording exception messages, and a maximum threshold value for the number of stored exception messages is set in the message storage. When the exception messages stored in the message storage exceed the maximum threshold value, the message sender will send the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message stored in the message storage to the corresponding consumer user for manual processing. This example sets a maximum threshold for the number of abnormal messages stored in the message storage. When the stored abnormal messages exceed the maximum threshold, all stored abnormal messages are sent to the corresponding consumer users for manual processing, saving resources of the message sender in sending the abnormal messages.

[0082] Optionally, the method further includes:

[0083] If the message in the abnormal message storage is pushed to a consumer user for processing, the message is deleted from the abnormal message storage.

[0084] In combination with the scenario example, the messages stored in the message storage are the unordered and unreliable exception messages or the ordered, independent, and irrecoverable exception messages and the first message that has a sequence relationship with the ordered, independent, and recoverable exception messages. If the exception messages in the message storage exceed the set maximum threshold, the message sender will send the ordered, independent, and irrecoverable exception messages or the ordered, independent, and recoverable exception messages and the first message that has a sequence relationship with them stored in the message storage to the corresponding consumer user and after manual processing, it will delete the exception messages stored in the message storage to facilitate the message storage to record and store other exception messages.

[0085] Optionally, if the type of the exception message to be processed is unordered and recoverable or ordered, dependent and recoverable, then the calling retryer processes the exception message to be processed again, including:

[0086] If the type of the pending exception message is unordered and recoverable or ordered, dependent and recoverable, the retryer is called to process the pending exception message again until the processing is successful or until the pending exception message is repeatedly processed by the retrieval device for a set number of times reaches the set number threshold, and then it is pushed to the consumer user through the message sender for processing.

[0087] In conjunction with the scenario example, for the ordered and recoverable or ordered-dependent and recoverable exception message, the retrieval device should be called to cyclically consume and process the latest message in the ordered and recoverable or the first message that has a sequential relationship with the ordered-dependent and recoverable exception message. The retrieval device is provided with a maximum threshold for the number of times the exception message is cyclically consumed. If the retrieval device successfully consumes and processes the exception message, the result is returned to the consumer, instructing the consumer to consume and process the subsequent pending messages in the message queue. Or when the number of times the retrieval device cyclically consumes the exception message reaches the maximum threshold and still fails to successfully consume and process the exception message, the message sender sends the exception message to the corresponding consumer user for manual processing.

[0088] This embodiment processes the abnormal message using a processing strategy suitable for the type of abnormal message based on whether the abnormal message is an ordered message, whether it has a dependency with other messages, and whether it is recoverable, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing.

[0089] Example 2

[0090] Figure 3 This is a schematic diagram of the structure of an abnormal message processing device provided in Example 2 of the present application, the device comprising:

[0091] An acquisition module 31 is configured to acquire type information of the exception message to be processed, including whether the message is an ordered message, whether it has dependencies with other messages, and whether the message is recoverable.

[0092] a determination module 32 for determining the type of the exception message to be processed according to the type information of the exception message to be processed; the types include unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable;

[0093] The processing module 33 is configured to perform corresponding processing on the abnormal message based on the processing strategy corresponding to each type and adopting the processing strategy corresponding to the type of the abnormal message to be processed.

[0094] In combination with the scenario example, the acquisition module 31 obtains the type information of the exception message to be processed, and the type information includes the error type corresponding to the exception message and the property classification of the message itself. The type information of the exception message to be processed can be roughly divided into six categories, namely: unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable. The determination module 32 determines the type of the exception message to be processed through the type information of the exception message to be processed. The processing module 33 sets a subsequent processing strategy for each type of exception data to be processed according to the six categories into which the exception message to be processed is divided, determines the processing strategy set for the exception message to be processed through the type of the exception message to be processed, completes the processing of the exception message to be processed according to the processing strategy corresponding to the exception message to be processed, and returns the processing result to the consumer.

[0095] The acquisition module of this example obtains the error type of the exception message to be processed and the nature of the message itself, and divides the exception message to be processed into six types: unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable. The determination module determines the type of the exception message to be processed through the type information of the exception message to be processed and sets a subsequent processing strategy for each type of exception data to be processed. Then, the processing module 33 processes the exception message using a processing strategy suitable for the type of the exception message according to whether the exception message belongs to an ordered message, whether there is a dependency relationship with other messages, and whether it is recoverable, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing.

[0096] Optionally, the processing module 33 is specifically configured to push the to-be-processed exception message to the consumer user for processing through the message sender if the type of the to-be-processed exception message is out of order and unrecoverable; and instruct the message processor to process the message after the to-be-processed exception message in the message queue;

[0097] The processing module 33 is further configured to call a retryer to process the exception message to be processed again if the type of the exception message to be processed is out of order and recoverable; and instruct a message processor to process messages after the exception message to be processed in the message queue;

[0098] The processing module 33 is further configured to, if the type of the to-be-processed exception message is ordered, independent, and unrecoverable, push the to-be-processed exception message and a first message that has a sequence relationship with the to-be-processed exception message to a consumer user for processing through a message sender; and instruct a message processor to process the to-be-processed exception message and messages subsequent to the first message in the message queue;

[0099] The processing module 33 is further configured to, if the type of the pending exception message is ordered, independent of dependencies, and recoverable, call a retryer to process the pending exception message again; if the processing is successful, return a success result to the message processor; if the processing fails, obtain the latest message in the first message from the message queue for processing;

[0100] The processing module 33 is further configured to, if the type of the pending exception message is an ordered dependency and recoverable, call the retryer to process the pending exception message again; if the processing is successful, return a success result to the message processor, and instruct the message processor to process the message after the pending exception message in the message queue;

[0101] The processing module 33 is specifically used to push the pending exception message to the consumer user through the message sender for processing if the type of the pending exception message is ordered dependency and cannot be recovered. If the processing is successful, the success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue.

[0102] Combined with the scenario example, if the messages to be delivered in the message queue are out of order, and the consumer generates an unrecoverable error in the process of consuming the messages to be delivered, resulting in an out-of-order and unrecoverable exception message, the processing module 33 sends it to the consumer user corresponding to the exception message through the message sender for manual processing based on the processing strategy corresponding to the out-of-order and unrecoverable exception message. Since the messages to be delivered in the message queue are out of order, whether the exception message is successfully consumed and processed does not affect the continued consumption and processing of other messages to be delivered in the message queue. Therefore, after the message sender sends the out-of-order and unrecoverable exception message to the corresponding consumer user for manual processing, the processing module 33 can instruct the message processor at the consumer to continue consuming and processing the next message to be delivered after the exception message. The consumer includes a message processor, and the consumer realizes message consumption processing through the message processor.

[0103] If the messages to be delivered in the message queue are out of order, and a recoverable error occurs in the process of consuming the messages to be delivered, resulting in an out-of-order and recoverable exception message, the processing module 33 can call the retryer to re-consume the out-of-order and recoverable exception message based on the processing strategy corresponding to the out-of-order and recoverable exception message. The retryer also includes a message processor, and the message processor in the retryer re-consumes the out-of-order and recoverable exception message and instructs the consumer to continue consuming the next out-of-order message in the message queue located after the exception message.

[0104] If the messages to be delivered in the message queue are ordered and independent of dependencies, and the consumer generates an unrecoverable error in the process of consuming the messages to be delivered, resulting in an ordered, independent, and unrecoverable exception message, the processing module 33 sends the ordered, independent, and unrecoverable exception message to the corresponding consumer user for manual processing through the message transmitter based on the processing strategy corresponding to the ordered, independent, and unrecoverable exception message. Since the messages to be delivered in the message queue are currently ordered, before the ordered, independent, and unrecoverable exception message is successfully consumed, the first message that has a sequence relationship with the ordered, independent, and unrecoverable exception message cannot be successfully consumed and processed by the consumer's message processor. The first message refers to other messages to be delivered that have a sequence relationship with the ordered, independent, and unrecoverable exception message. Therefore, based on the processing strategy corresponding to the ordered, independent, and unrecoverable exception message, the processing module 33 sends the ordered, independent, and unrecoverable exception message to the corresponding consumer user for manual processing through the message transmitter, and also sends the first message to the corresponding consumer user for manual processing. And instruct the consumer to continue consuming and processing the ordered, independent, and irrecoverable exception message and the messages to be transmitted after the first message.

[0105] If the messages to be delivered in the message queue are ordered and independent of dependencies, and a recoverable error occurs in the process of the consumer consuming the messages to be delivered, resulting in an ordered, independent, and recoverable exception message, the processing module 33 calls the retrieval device to re-consume the ordered, independent, and recoverable exception message based on the processing strategy corresponding to the ordered, independent, and recoverable exception message. If the retrieval device successfully re-consumes the ordered, independent, and recoverable exception message, the result is returned to the consumer, and the consumer will continue to consume and process the next message to be delivered. If the retrieval device fails to successfully re-consume the ordered, independent, and recoverable exception message, the retrieval device obtains the latest message in the first message that has a sequential relationship with the ordered, independent, and recoverable exception message from the message queue, and re-consumes and processes the latest message. The retrieval device also instructs the consumer to continue consuming and processing the ordered, independent, and recoverable exception message and the messages to be transmitted after the first message.

[0106] If the messages to be delivered in the message queue are ordered dependent, and the consumer generates a recoverable error in the process of consuming the messages to be delivered, resulting in an ordered dependent and recoverable exception message, the processing module 33 calls the retryer to consume the ordered dependent and recoverable exception message again based on the processing strategy corresponding to the ordered dependent and recoverable exception message. Since the messages to be delivered in the message queue are ordered dependent, the consumer can only consume and process the subsequent messages to be delivered after the exception message is successfully consumed, and the error type of the exception message is recoverable, so the retryer can be continuously called to consume and process the exception message.

[0107] If the messages to be delivered in the message queue are ordered-dependent, and the consumer generates an unrecoverable error in the process of consuming the messages to be delivered, resulting in an ordered-dependent and unrecoverable exception message, the processing module 33 can send the ordered-dependent and unrecoverable exception message to the corresponding consumer user for consumption processing through the message sender based on the processing strategy corresponding to the ordered-dependent and unrecoverable exception message. Similar to the ordered-dependent and recoverable exception message, the messages to be delivered in the message queue are ordered-dependent, so the consumer can only consume and process the subsequent messages to be delivered after the exception message is successfully consumed. However, the current exception message error type is unrecoverable, so the retryer cannot be called to repeatedly consume it, and it can only be sent to the corresponding consumer user for consumption processing until the consumption of the exception message is completed.

[0108] The processing module of this example processes the abnormal message according to the processing strategy corresponding to each type, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of consumer message processing.

[0109] Optionally, the processing module 33 is further configured to store the exception message to be processed in an exception message storage;

[0110] The processing module 33 is further configured to push all messages in the abnormal message storage, including the abnormal message to be processed, to the consumer user for processing via a message sender if the message data in the abnormal message storage currently reaches a set threshold.

[0111] According to the scenario example, for the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message, before sending the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message to the corresponding consumer user for manual processing, the processing module 33 may first store the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message in the message memory. The message memory is responsible for storing and recording exception messages, and a maximum threshold value for the number of stored exception messages is set in the message memory. When the exception messages stored in the message memory exceed the maximum threshold value, the processing module 33 will send the unordered and irrecoverable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message stored in the message memory to the corresponding consumer user for manual processing. This example sets a maximum threshold for the number of abnormal messages stored in the message memory. When the stored abnormal messages exceed the maximum threshold, the processing module 33 sends all stored abnormal messages to the corresponding consumer users for manual processing, saving resources of the message sender in sending the abnormal messages.

[0112] Optionally, the processing module 33 is further configured to delete the message from the abnormal message storage if the message in the abnormal message storage is pushed to a consumer user for processing.

[0113] Combined with the scenario example, the message stored in the message storage is the unordered and unreliable exception message or the ordered, independent and irrecoverable exception message and the first message that has a sequence relationship with the ordered, independent and recoverable exception message. If the exception message in the message storage exceeds the set maximum threshold, the processing module 33 will send the ordered, independent and irrecoverable exception message or the ordered, independent and recoverable exception message and the first message that has a sequence relationship with it stored in the message storage to the corresponding consumer user and perform manual processing, and will delete the exception message stored in the message storage to facilitate the message storage to record and store other exception messages.

[0114] Optionally, the processing module 33 is further used to call the retryer to process the pending exception message again if the type of the pending exception message is unordered and recoverable or ordered, dependent and recoverable, until the processing is successful or until the pending exception message is repeatedly processed by the retrieval device for a set number of times reaches a set threshold, and then push it to the consumer user for processing through the message sender.

[0115] In combination with the scenario example, for the ordered and recoverable or ordered dependent and recoverable exception message, the processing module 33 should call the retryer to cyclically consume and process the latest message in the ordered and recoverable or the first message that has a sequential relationship with the ordered dependent and recoverable exception message. The retrieval device is provided with a maximum threshold for the number of times of cyclic consumption of exception messages. If the retrieval device successfully consumes and processes the exception message, the processing module 33 returns the result to the consumer, instructing the consumer to consume and process the subsequent pending messages in the message queue. Or when the number of times the retrieval device cyclically consumes the exception message reaches the maximum threshold and still fails to successfully consume and process the exception message, the processing module 33 sends the exception message to the corresponding consumer user for manual processing.

[0116] In this embodiment, the acquisition module obtains the type information of the exception message, the determination module determines the type of the exception message through the type information of the exception message, and the processing module processes the exception message using a processing strategy suitable for the type of the exception message based on whether the exception message is an ordered message, whether it has a dependency relationship with other messages, and whether it is recoverable, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing.

[0117] Example 3

[0118] Figure 4A structural diagram of an abnormal message processing system is provided for the third embodiment of the present application, which is equivalent to the processing module in the abnormal message processing device provided in the second embodiment of the present application. The system includes: a rule configurator, a rule storage, a rule adjudicator, a retryer, a message sender, and an abnormal data storage. Among them, the rule configurator configures the processing rules of the abnormal message, Figure 5 This is a schematic diagram of the rule configurator structure, such as Figure 5 As shown, the rule configurator includes four units, namely a business data configuration unit, a message sending configuration unit, an error type configuration unit, and a retry rule configuration unit. The four configuration units of the rule configurator configure the business data rules, message sending rules, error type rules, and retry rules respectively. The business data rules include recording the business code of the abnormal message, whether the message data is ordered, and whether there is a dependency between the order of the message data. The error type rules include recording whether the abnormal message is recoverable. The message sending rules include stipulating the maximum threshold for the number of abnormal messages stored in the abnormal data memory and the maximum threshold for the number of times the retryer is called. The retry rules include recording the number of times the retryer is called to consume and process abnormal messages. The rule configurator stores the configured rules in the rule memory.

[0119] The rule adjudicator consists of a recovery judgment operator, a sequential judgment operator, a retry monitoring unit, and a data monitoring unit. After the rule adjudicator obtains the processing rule corresponding to the exception message from the rule storage, the recovery judgment operator is responsible for determining whether the error type of the exception message is a recoverable error type; the sequential judgment operator is responsible for determining whether the exception message has a sequence and whether the latter depends on the execution result of the former based on the business data rules; the retry monitoring unit is responsible for monitoring the number of times the retryer is called; and the data monitoring unit is responsible for monitoring the number of messages stored in the exception data storage.

[0120] Figure 6 This is the workflow diagram of the retryer. First, the number of calls in the retryer is initialized. When the retryer re-consumes and processes the current exception message, if the consumption is successful, a success result is returned. If the consumption fails, the retry rule stored in the rule memory is queried to determine whether the maximum threshold of the number of calls specified by the retryer has been reached. If so, a retry failure error code is returned. The rule arbiter sends the current exception message to the corresponding consumer user through the message sender for processing based on the error code. If the maximum threshold of the number of calls specified by the retryer has not been met, the number of times in the retryer is increased and attempts to consume the current exception message continue.

[0121] Figure 7This is the overall workflow diagram of the exception message processing system. First, the rule configurator configures the processing rules for each type of exception message and then stores the processing rules for each type of exception message in the rule memory. The rule adjudicator first classifies the exception messages and obtains the processing rules for each type of exception message from the rule memory. If the type of the exception message is unordered and irrecoverable or ordered, independent, and irrecoverable, the rule adjudicator stores the exception message in the exception message memory and queries whether the message sending rules are met. The message sending rules include the maximum threshold for the number of exception messages stored in the exception data memory and the maximum threshold for the number of times the retryer is called. If the sending rules are met, the rule arbiter will send the exception message to the corresponding consumer user for consumption processing; if the type of the exception message is ordered, dependent and irrecoverable, the rule arbiter will directly send the exception message to the corresponding consumer user for consumption processing; if the type of the exception message is neither unordered and irrecoverable nor ordered, independent and irrecoverable nor ordered, dependent and irrecoverable, the rule arbiter will call the retryer to re-consume the exception message and query whether the message sending rules are met. If the sending rules are met, the rule arbiter will send the exception message to the corresponding consumer user for consumption processing; after consuming and processing different types of exception messages, the processing results are returned to the consumer, thereby continuing to process subsequent exception messages.

[0122] Figure 8For the processing rules corresponding to out-of-order exception messages, the rule arbiter first queries the error type configuration unit of the rule memory to determine whether the error type of the out-of-order exception message is recoverable. If the error type of the exception message is unrecoverable, the exception message is stored in the exception message memory, and the sending rule configuration unit of the rule memory is used to query whether the number of exception messages stored in the exception message memory has reached a specified maximum threshold. If the maximum threshold has been reached, the rule arbiter calls the message sender to send the exception message stored in the exception message memory to the corresponding consumer for consumption processing. If the error type of the exception message is recoverable, the rule arbiter calls the retryer, which then re-consumes the exception message. Each time the retryer is called, the call count of the retryer is incremented by 1. If the retryer successfully consumes the exception message, the task is terminated. If the retryer fails to consume the exception message, the retryer is called again, and the exception message consumption is processed in a cyclic manner. If the retry monitoring unit in the retryer monitors that the number of times the retryer is called reaches the maximum threshold for calling the retryer configured by the rule arbitrator, the rule arbitrator will call the message sender to send the exception message stored in the exception message storage to the corresponding consumer user for consumption processing.

[0123] Figure 9 For the processing rules corresponding to ordered and independent exception messages, the rule arbiter first queries the error type configuration unit of the rule memory to see whether the error type of the ordered and independent exception message is recoverable. If the error type of the exception message is unrecoverable, the exception message is stored in the exception message memory, and the sending rule configuration unit of the rule memory is queried to see whether the number of exception messages stored in the exception message memory reaches a specified maximum threshold. If the maximum threshold is reached, the rule arbiter calls the message sender to send the exception message stored in the exception message memory to the corresponding consumer for consumption processing. If the error type of the exception message is recoverable, the rule arbiter calls the retryer, which re-consumes the latest message in the first message that has a sequential relationship with the exception message. If the retryer successfully consumes the latest message, the task is terminated. If the latest message is not successfully consumed, the retryer is called again to cyclically consume the latest message in the first message that has a sequential relationship with the exception message according to this rule. If the retry monitoring unit in the retryer monitors that the number of times the retryer is called reaches the maximum threshold for calling the retryer configured by the rule arbitrator, the rule arbitrator will call the message sender to send the exception message stored in the exception message storage to the corresponding consumer user for consumption processing.

[0124] Figure 10 For the processing rules corresponding to ordered dependent exception messages, the rule arbiter first queries the error type configuration unit of the rule memory to see whether the error type of the ordered and non-dependent exception message is recoverable. If the error type of the exception message is unrecoverable, the rule arbiter directly calls the message sender to send the exception message to the corresponding consumer user for consumption processing. If the error type of the exception message is recoverable, the rule arbiter calls the retryer, and the retryer re-consumes and processes the exception message. If the retryer successfully consumes the latest message, the task is terminated. If the latest message is not successfully consumed, the retryer is called again, and the exception message is consumed in a cyclic manner according to this rule. If the retry monitoring unit in the retryer monitors that the number of times the retryer is called reaches the maximum threshold for calling the retryer configured by the rule arbiter, the rule arbiter will call the message sender to send the exception message to the corresponding consumer user for consumption processing.

[0125] This embodiment processes the abnormal message based on the type of the abnormal message and the corresponding processing strategy of the abnormal message, and processes the abnormal message according to the processing strategy corresponding to each type, thereby avoiding message congestion and resource waste in the message queue and improving the efficiency of message processing.

[0126] Example 4

[0127] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, such as Figure 11 As shown, the electronic device includes:

[0128] The electronic device includes a processor 291 and a memory 292; a communication interface 293, and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via bus 294. Communication interface 293 can be used for information transmission. The processor 291 can invoke logic instructions in memory 292 to execute the methods of the above embodiments.

[0129] In addition, the logic instructions in the memory 292 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

[0130] Memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of the present disclosure. Processor 291 executes the software programs, instructions, and modules stored in memory 292 to perform functional applications and data processing, thereby implementing the methods in the above-mentioned method embodiments.

[0131] Memory 292 may include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data generated based on the use of the terminal device. Memory 292 may also include high-speed random access memory and non-volatile memory.

[0132] An embodiment of the present disclosure provides a non-transitory computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the method described in the above embodiment.

[0133] Example 5

[0134] An embodiment of the present disclosure provides a computer program product, including a computer program. When the computer program is executed by a processor, the private network data collection method provided by any embodiment of the present disclosure is implemented.

[0135] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the following claims.

[0136] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for handling abnormal messages, characterized in that: The method comprises: Obtain type information of the exception message to be processed, including whether it is an ordered message, whether it has dependencies with other messages, and whether it is recoverable; Determine the type of the exception message to be processed according to the type information of the exception message to be processed; the types include unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable; Based on the processing strategies corresponding to each type, the processing strategy corresponding to the type of the abnormal message to be processed is adopted to perform corresponding processing on the abnormal message; The processing strategy corresponding to each type is adopted based on the processing strategy corresponding to the type of the exception message to be processed, and the corresponding processing is performed on the exception message to be processed, including: If the type of the pending exception message is out of order and unrecoverable, the pending exception message is pushed to the consumer user through the message sender for processing; and the message processor is instructed to process the message after the pending exception message in the message queue; If the type of the pending exception message is out of order and recoverable, calling the retryer to process the pending exception message again; and instructing the message processor to process the message after the pending exception message in the message queue; If the type of the pending exception message is ordered, independent, and irrecoverable, the pending exception message and a first message that has a sequence relationship with the pending exception message are pushed to the consumer user for processing through the message sender; and the message processor is instructed to process the pending exception message and the messages after the first message in the message queue; If the type of the pending exception message is ordered, independent, and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor. If the processing fails, the latest message in the first message is obtained from the message queue for processing; If the type of the pending exception message is ordered dependency and recoverable, the retryer is called to process the pending exception message again. If the processing is successful, a success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue; If the type of the pending exception message is ordered dependency and cannot be recovered, the pending exception message will be pushed to the consumer user through the message sender for processing. If the processing is successful, the success result will be returned to the message processor, and the message processor will be instructed to process the messages after the pending exception message in the message queue.

2. The method according to claim 1, characterized in that If the type of the exception message to be processed is unordered and irrecoverable or ordered, independent of dependency and irrecoverable, the exception message to be processed is pushed to the consumer user through the message sender for processing, including: Storing the to-be-processed exception message in an exception message storage; If the message data in the current abnormal message storage reaches a set threshold, all messages in the abnormal message storage, including the abnormal message to be processed, are pushed to the consumer user through the message sender for processing.

3. The method according to claim 2, characterized in that The method further comprises: If the message in the abnormal message storage is pushed to a consumer user for processing, the message is deleted from the abnormal message storage.

4. The method according to any one of claims 1 to 3, characterized in that If the type of the exception message to be processed is unordered and recoverable or ordered dependent and recoverable, the calling retryer processes the exception message to be processed again, including: If the type of the pending exception message is unordered and recoverable or ordered, dependent and recoverable, the retryer is called to process the pending exception message again until the processing is successful or until the pending exception message is repeatedly processed by the retrieval device for a set number of times reaches the set number threshold, and then it is pushed to the consumer user through the message sender for processing.

5. An abnormal message processing device, characterized in that: The device comprises: An acquisition module is used to obtain type information of the exception message to be processed, the type information including whether it is an ordered message, whether it has a dependency relationship with other messages, and whether it is recoverable; a determination module, configured to determine the type of the exception message to be processed according to the type information of the exception message to be processed; the types including unordered and irrecoverable, unordered and recoverable, ordered without dependency and irrecoverable, ordered without dependency and recoverable, ordered with dependency and recoverable, and ordered with dependency and irrecoverable; A processing module, configured to perform corresponding processing on the abnormal message using the processing strategy corresponding to the type of the abnormal message to be processed based on the processing strategy corresponding to each type; The processing module is specifically configured to push the exception message to be processed to the consumer user through the message sender for processing if the type of the exception message to be processed is disordered and unrecoverable; and instruct the message processor to process the message after the exception message to be processed in the message queue; The processing module is further configured to call a retryer to process the exception message to be processed again if the type of the exception message to be processed is out of order and recoverable; and instruct a message processor to process messages subsequent to the exception message to be processed in the message queue; The processing module is further configured to, if the type of the to-be-processed exception message is ordered, independent of dependency, and irrecoverable, push the to-be-processed exception message and a first message that has a sequence relationship with the to-be-processed exception message to a consumer user for processing through a message sender; and instruct a message processor to process the to-be-processed exception message and messages subsequent to the first message in the message queue; The processing module is further configured to, if the type of the to-be-processed exception message is ordered, independent of dependencies, and recoverable, call a retryer to process the to-be-processed exception message again; if the processing is successful, return a success result to the message processor; if the processing fails, obtain the latest message in the first message from the message queue for processing; The processing module is further configured to, if the type of the to-be-processed exception message is an ordered dependency and recoverable, call a retryer to process the to-be-processed exception message again; if the processing is successful, return a success result to the message processor, and instruct the message processor to process the message after the to-be-processed exception message in the message queue; The processing module is specifically used to push the pending exception message to the consumer user through the message sender for processing if the type of the pending exception message is ordered dependency and cannot be recovered. If the processing is successful, the success result is returned to the message processor, and the message processor is instructed to process the message after the pending exception message in the message queue.

6. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the abnormal message processing method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the abnormal message processing method according to any one of claims 1 to 4.

8. A computer program product, characterized in that The invention comprises a computer program, which implements the abnormal message processing method according to any one of claims 1 to 4 when executed by a processor.

Images