CN107908494A - Abnormal event processing method, device, electronic equipment and storage medium - Google Patents

Abstract

The embodiment of the invention provides a method and a device for processing an abnormal event, electronic equipment and a storage medium, and relates to the technical field of data processing. The method comprises the following steps: detecting whether an abnormal event occurs or not in the execution process of the service; if the abnormal event is detected to occur, storing an abnormal message corresponding to the abnormal event in a target database; reading the abnormal message stored in the target database, and performing retry processing on the corresponding service according to the read abnormal message; deleting the read exception message from the target database when the retry is successful. The technical scheme of the embodiment of the invention can automatically retry the abnormal business without human intervention, greatly saves the investment of manpower and material resources and can improve the processing efficiency of abnormal events.

Description

Abnormal event processing method, device, electronic equipment and storage medium

technical field

Embodiments of the present invention relate to the technical field of data processing, and in particular, relate to a method for processing an abnormal event, an apparatus for processing an abnormal event, electronic equipment, and a computer-readable storage medium.

Background technique

With the development of computer technology, the business system has become more and more complex. When the business system runs for a long time, there is no guarantee that there will be no problems such as network flashing. Data will be lost.

In the current technical solution, when an abnormal situation occurs, the problem is generally solved by retrying. However, this retrying method requires maintenance personnel to manually trigger the retrying operation according to different services. Therefore, the current technical solution not only needs to invest a lot of manpower and material resources, but also consumes a lot of time for manual operation, which greatly reduces the processing efficiency of abnormal events.

It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those of ordinary skill in the art.

Contents of the invention

The purpose of the embodiments of the present invention is to provide a method for processing abnormal events, a device for processing abnormal events, an electronic device, and a computer-readable storage medium, so as to solve the problem of low efficiency in processing abnormal events and the need for a large amount of manpower and material resources at least to a certain extent. The question of cost.

According to the first aspect of an embodiment of the present invention, a method for processing an abnormal event is provided, including: during the execution of the business, detecting whether an abnormal event occurs; if the abnormal event is detected, storing the abnormal event in the target database An abnormal message corresponding to the abnormal event; read the abnormal message stored in the target database, and retry the corresponding business according to the read abnormal message; delete it from the target database when the retry is successful The exception message read.

In some embodiments of the present invention, based on the foregoing solution, after retrying the corresponding business according to the read exception message, it further includes: when the retry fails, accumulating the number of retries corresponding to the read exception message ; Wherein, reading the abnormal message stored in the target database includes: reading the corresponding abnormal message in the target database whose number of retries is less than a predetermined number.

In some embodiments of the present invention, based on the aforementioned solutions, reading the abnormal messages stored in the target database includes: regularly reading the abnormal messages stored in the target database according to a predetermined period.

In some embodiments of the present invention, based on the foregoing solution, before storing the abnormal message corresponding to the abnormal event in the target database, further includes: parsing the abnormal event to obtain the abnormal message corresponding to the abnormal event .

In some embodiments of the present invention, based on the aforementioned solution, during the execution of the business, detecting whether an abnormal event occurs includes: when calling multiple objects in the same transaction, if the call to any object fails, the Rollback processing is performed on the call process that has occurred; if it is detected that the rollback of the call process that has occurred fails, it is determined that an abnormal event in the rollback business has been detected.

In some embodiments of the present invention, based on the foregoing solution, storing the exception message corresponding to the abnormal event in the target database includes: storing in the target database a message of rollback failure of the call process that has occurred.

In some embodiments of the present invention, based on the aforementioned solutions, rolling back the call process that has occurred includes: obtaining the corresponding callback path according to the identifier of the transaction; calling the callback method based on the callback path, and according to The callback method rolls back the calling process that has occurred.

In some embodiments of the present invention, based on the foregoing solution, when each of the multiple objects is called, the identifier of the transaction and the corresponding callback path are recorded.

In some embodiments of the present invention, based on the foregoing solution, after recording the transaction identifier and the corresponding callback path, it further includes: if it is detected that the rollback of the call process that has occurred is successfully rolled back, then delete the call process The identifier of the transaction recorded by any object and the corresponding callback path.

In some embodiments of the present invention, based on the aforementioned solution, after recording the identifier of the transaction and the corresponding callback path, it further includes: if all the calls to the multiple objects are successful, then delete the recorded connection with the transaction All information related to the identity.

In some embodiments of the present invention, based on the foregoing solution, further comprising: if the call to any object is successful, continue to call the next object in the multiple objects according to the calling sequence until all the calls to the multiple objects are completed .

In some embodiments of the present invention, based on the foregoing solution, the multiple target objects are nodes in a distributed system.

According to the second aspect of the embodiments of the present invention, there is provided a device for processing abnormal events, including: an abnormal detection unit, used to detect whether an abnormal event occurs during the execution of a business; an abnormal storage unit, used to detect When the abnormal event occurs, an abnormal message corresponding to the abnormal event is stored in the target database; a retry unit is configured to read the abnormal message stored in the target database, and perform corresponding processing according to the read abnormal message. The business performs retry processing; the deletion unit is configured to delete the read abnormal message from the target database when the retry succeeds.

According to a third aspect of the embodiments of the present invention, there is provided an electronic device, including: a processor; and a memory, where computer-readable instructions are stored in the memory, and the computer-readable instructions are implemented when executed by the processor. The method for handling the abnormal event as described in the first aspect above.

According to a fourth aspect of the embodiments of the present invention, there is provided a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method for processing an abnormal event as described in the above-mentioned first aspect is implemented. .

In the technical solution provided by some embodiments of the present invention, when an abnormal event is detected, the abnormal message corresponding to the abnormal event is stored in the target database; Retry processing, delete the exception message when the retry succeeds. On the one hand, when an abnormal event is detected, the abnormal message corresponding to the abnormal event is stored in the target database, which can ensure that the abnormal message will not be lost; on the other hand, the corresponding business is processed according to the abnormal message in the target database read Retry processing, delete the abnormal message when the retry is successful, so that the abnormal business can be automatically retried without human intervention, which greatly saves the investment of manpower and material resources; on the other hand, due to the abnormal detection and storage The message process and the process of reading and processing the exception message are asynchronous, so the processing efficiency of the exception event can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description serve to explain the principles of the invention. Apparently, the drawings in the following description are only some embodiments of the present invention, and those skilled in the art can obtain other drawings according to these drawings without creative efforts. In the attached picture:

FIG. 1 shows a schematic flowchart of a method for processing an abnormal event according to a first embodiment of the present invention;

Fig. 2 shows a schematic block diagram of an abnormal event processing system according to an exemplary embodiment of the present invention;

FIG. 3 shows a schematic flowchart of a method for processing an abnormal event according to a second embodiment of the present invention;

Fig. 4 shows a schematic diagram of the process of calling multiple objects according to an exemplary embodiment of the present invention;

FIG. 5 shows a schematic flowchart of a method for processing an abnormal event according to a third exemplary embodiment of the present invention;

Fig. 6 shows a schematic block diagram of an abnormal event processing device according to an exemplary embodiment of the present invention;

FIG. 7 shows a schematic structural diagram of a computer system suitable for implementing the electronic device of the embodiment of the present invention.

Detailed ways

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals denote the same or similar parts in the drawings, and thus their repeated descriptions will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided in order to give a thorough understanding of embodiments of the invention. However, those skilled in the art will appreciate that the technical solutions of the present invention may be practiced without one or more of the specific details, or other methods, components, means, steps, etc. may be employed. In other instances, well-known methods, apparatus, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the invention.

The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices entity.

The flow charts shown in the drawings are only exemplary illustrations, and do not necessarily include all contents and operations/steps, nor must they be performed in the order described. For example, some operations/steps can be decomposed, and some operations/steps can be combined or partly combined, so the actual order of execution may be changed according to the actual situation.

Fig. 1 shows a schematic flowchart of a method for processing an abnormal event according to a first embodiment of the present invention.

Referring to Fig. 1, the processing method of the abnormal event may include the following steps:

Step S110, during the execution of the business, detect whether an abnormal event occurs;

Step S120, if the occurrence of the abnormal event is detected, storing an abnormal message corresponding to the abnormal event in the target database;

Step S130, reading the abnormal message stored in the target database, and retrying the corresponding business according to the read abnormal message;

Step S140, when the retry succeeds, delete the read exception message from the target database.

In the processing method of the abnormal event shown in Figure 1, on the one hand, when the abnormal event is detected, the abnormal message corresponding to the abnormal event is stored in the target database, which can ensure that the abnormal message will not be lost; on the other hand, according to the read The exception messages stored in the target database retry the business corresponding to the exception message, and delete the exception message when the retry is successful, so that the abnormal business can be retried automatically without human intervention, which greatly saves manpower and material resources; on the other hand, since the process of detecting and storing abnormal messages and the process of reading abnormal messages for processing are asynchronous, it can improve the processing efficiency of abnormal events.

Next, the method for handling abnormal events in this exemplary embodiment will be described in detail with reference to the accompanying drawings.

Referring to FIG. 1 , in step S110 , during the execution of the service, it is detected whether an abnormal event occurs.

Optionally, the abnormal event processing method shown in FIG. 1 may be executed by the abnormal event processing system according to the exemplary embodiment of the present invention shown in FIG. 2 . Referring to FIG. 2 , the abnormal event processing system may include: an abnormal event publisher 210 , an abnormal message processing engine 220 , a scheduled task trigger 230 , an abnormal service retry engine 240 and a database 250 .

In this exemplary embodiment, when an exception occurs in the process of executing a business, an exception event may be issued to the exception message processing engine 220 through the exception event publisher 210, and the exception event may include the occurrence time of the exception event and the message body corresponding to the exception event (such as the message itself in the message sending service), the error message where the exception occurred, and the target queue corresponding to the abnormal event (such as the queue where the sent message in the message sending service is located) and so on.

It should be noted that, in this example embodiment, the abnormal event may be message sending failure, business rollback failure, etc., but the abnormal event in the example embodiment of the present invention is not limited to this, for example, it may also be message receiving failure, message Abnormal events such as reading failure and network flash disconnection are also within the protection scope of the present invention.

Next, referring to FIG. 1 , in step S120, if the abnormal event is detected, an abnormal message corresponding to the abnormal event is stored in the target database.

Continuing to refer to FIG. 2 , in this exemplary embodiment, the exception message processing engine 220 may analyze the content of the exception event, and store the corresponding exception message in the exception message retry table in the database 250 . Further, the number of retries corresponding to the stored exception messages in the database 250 may also be recorded in the exception message retry table. The structure of the exception message retry table in this exemplary embodiment is shown in Table 1 below.

Table 1

Next, in step S130, the abnormal message stored in the target database is read, and the corresponding service is retried according to the read abnormal message.

Continuing to refer to Fig. 2, in this exemplary embodiment, the timed task trigger 230 can regularly trigger the abnormal service retry engine 240 according to the configured timing rule to query the abnormal message recorded in the abnormal message retry table from the database 250 to The exception message retry engine 240 is triggered to perform the exception message retry task.

Further, in this exemplary embodiment, when the exception message retry engine 240 receives the trigger instruction from the timing task trigger 230, it will extract the number of retries less than the predetermined number of times, for example, 3 times (the specific value is only an example here) exception message, and then retry the service corresponding to the extracted exception message. After the retry of the service corresponding to the exception message succeeds, the exception message is deleted from the exception message retry table; when the retry fails, the number of retries of the exception message is increased by 1. If the service corresponding to an exception message fails to succeed after three retries, the service corresponding to the exception message may have a problem that cannot be automatically recovered, and manual intervention is required for processing.

In addition, in this example embodiment, for the message sending service, the message may be sent to the receiving end multiple times when the service is retried. Therefore, in order to avoid repeated processing of the same message at the receiving end, a message table can also be created at the message receiving end to record the processed messages, avoiding the repeated processing of the same message at the message receiving end, and ensuring the power of the message between the message sending end and the message receiving end equivalence.

Continuing to refer to FIG. 1 , in step S140, when the retry is successful, the read exception message is deleted from the target database.

In this exemplary embodiment, in order to avoid retrying by reading the exception message again after the service retry succeeds, the recorded exception message may be deleted from the exception message retry table in the target database when the retry succeeds.

The abnormal event processing method in the above embodiment can automatically retry the abnormal business without human intervention, which greatly saves the input of manpower and material resources, and because the process of detecting and storing abnormal messages is not the same as reading abnormal messages The process of processing is performed asynchronously, so the processing efficiency of abnormal events can be improved.

Fig. 3 shows a schematic flowchart of a method for processing an abnormal event according to a second embodiment of the present invention.

Referring to FIG. 3, in step S310, a timed task trigger triggers a timed task. Specifically, the timing task trigger 230 shown in FIG. 2 can periodically trigger the exception message retry engine 240 to execute the retry task according to the configured timing rules. It should be noted that, among the various steps shown in FIG. 3 , except step S310 , other steps may be executed by the exception message retry engine 240 shown in FIG. 2 .

In step S320, the exception message stored in the exception message retry table is read. The exception message in the exception message retry table may include the number of retries of the corresponding service.

In step S330, it is judged whether the service corresponding to the abnormal message has been retried a predetermined number of times, for example, 3 times; If the predetermined number of times is exceeded, step S340 is executed.

In step S340, the retry operation of the service corresponding to the abnormal message is performed.

Further, in step S350, it may be determined whether the retry operation in step S340 is successful, and if it is determined in step S350 that the retry operation is successful, step S360 is performed; when it is determined in step S350 that the retry operation is unsuccessful, step S370 is performed.

In step S360, delete the exception message stored in the exception message retry table.

In step S370, add 1 to the number of retries of the exception message.

Since the specific details of the method for handling the abnormal event in this example embodiment are similar to those in the above-mentioned first embodiment, details will not be repeated here. Similarly, the method for handling abnormal events shown in FIG. 3 can also automatically retry abnormal services, and can also improve the processing efficiency of abnormal events.

Fig. 4 shows a schematic diagram of another abnormal event processing system according to an exemplary embodiment of the present invention.

Referring to FIG. 4 , in the same transaction, service D needs to call object A, object B, and object C in sequence. In order to ensure the data consistency when multiple objects need to be called in one transaction, when service D fails to call any object in object A, object B, or object C, it is necessary to Perform rollback, for example, when calling object B fails, the process of calling object A and object B needs to be rolled back. Once the rollback fails, message inconsistency will occur throughout the system, which will cause some erroneous data in the system. Therefore, the exception message can be stored in an intermediate table such as a local message table, and the business that fails to be rolled back can be retried through the exception event processing method in the above example embodiment according to the stored exception message until the exception message is sent to the server after the retry succeeds. Deleted to ensure message consistency across the system.

It should be noted that, in this example embodiment, multiple objects may be multiple business logics (such as business objects) in the same system, or multiple nodes in a distributed system (such as server node), both cases are within the protection scope of the present invention. The processing procedure shown in Figure 4 is described in detail below:

Referring to Figure 4, in this example embodiment, when service D calls object A, object B, and object C sequentially in the same transaction, it needs to call the local message table to record relevant information to ensure message consistency. Optional Specifically, the local message table can at least include the following contents: (1) transaction number; (2) callback service address (that is, the callback path, used for data rollback); (3) whether the rollback is abnormal. The following table 2 shows the information of each field of the local message table message_log in an example embodiment of the present invention:

Field Name Field Type Remark id varchar(64) Uniquely identifies transaction_id int(4) transaction number callback_url varchar Callback service address status int(4) Is the rollback abnormal?

Table 2

In the embodiment shown in FIG. 4 , before calling object A, service D needs to record the transaction number T and the callback service address (that is, the callback path) for rolling back the object A service in the local message table. If the call to object A fails, data rollback will be performed according to the callback service address; if service D succeeds in calling object A, continue to call object B.

Before service D calls object B, it also needs to record transaction number T and callback service address in the local message table. If the call to object B fails, it is necessary to roll back the calling process that has already occurred.

The specific method of rollback is: query the previously recorded callback service address from the local message table according to the transaction number T, and call the corresponding callback method according to the callback service address to roll back the call process that has occurred. If the rollback failure is detected, the recorded transaction number T and the callback service address are kept, and the message of the rollback failure of the call process that has occurred is stored in the local message table, for example, the local message table shown in Table 2 The exception message corresponding to the rollback exception is stored under the field whose field name is status (status).

Further, in order to handle the abnormal event of rollback failure, a processing method similar to the abnormal event shown in FIG. 1 can be adopted. Specifically, the abnormal message can be read from the local message table periodically, The retrieved exception message obtains the callback service address under the same transaction corresponding to the exception message, and rolls back the call process that has occurred according to the callback service address. Optionally, the number of rollback failures may also be recorded in the local message table, so that when the number of rollback failures reaches a predetermined number, manual intervention is performed.

When the rollback of the calling process that has occurred is successful, delete the transaction number, callback service address and exception message of the rollback exception recorded in the local message table.

If service D calls object B successfully, it continues to call object C.

The processing process of service D's call to object C is basically similar to the processing process of service D's call to object B. It should be noted that since object C is the last object to be called, when the call to object C is successful, all information related to transaction T can be deleted, that is, all information related to transaction T recorded in the local message table.

FIG. 5 specifically shows the processing flow of the calling process shown in FIG. 4 . Referring to FIG. 5 , under the same transaction, service D needs to call object A, object B, and object C in sequence. Each step is described in detail below:

In step S502, the service D records the transaction number T, the message serial number (the message serial number is optional and not necessary) and the callback function address of the object A in the local message table.

In step S504, object A is called.

In step S506, it is determined whether the invocation of object A by service D is successful, if it is determined in step S506 that invocation of object A is successful, then step S510 is executed; if in step S506 it is determined that invocation of object A fails, then step S508 is executed.

In step S508, data rollback processing is performed. During the rollback process, the callback function address recorded before calling the object A can be obtained according to the transaction number T, and the callback method is called to perform the rollback process based on the callback function address.

In step S510, record the transaction number T, message serial number and callback function address in the local message table.

In step S512, object B is invoked.

Next, it is judged in step S514 whether the call to object B is successful; if it is judged in step S514 that the call to object B is successful, then step S524 is executed; if the call to object B fails, then step S516 is executed.

In step S516, the recorded callback service address is queried according to the transaction number T, and the callback method is invoked according to the callback service address to roll back the calling process that has occurred.

Further, in step S518, it is judged whether the callback is successful; if it is judged in step S518 that the callback is successful, then step S520 is executed; if it is judged that the callback fails, the abnormal message of callback failure can be recorded in the local message table, and then step S522 is executed .

In step S520, delete the transaction number T, message serial number and callback address recorded in step S510.

In step S522, wait for the scheduled task to retry. That is, the scheduled task regularly reads the information recorded in the local message table, and rolls back the call process that has occurred until the callback succeeds, and then deletes the transaction number T, message serial number, callback address, and callback address recorded in the local message table. Record whether the roll is abnormal or not. Of course, it can also be handled by manual intervention after the predetermined number of retries still fail to roll back.

In step S524, record the transaction number T, message serial number and callback function address in the local message table.

In step S526, object C is invoked.

Next, in step S528, it is judged whether the call to object C is successful; if it is judged in step S528 that the call to object C is successful, then step S530 is executed; if the call to object C fails, then step S516 is executed.

In step S530, according to the transaction number T, all records related to the transaction number T are deleted.

In the technical solution of the embodiment shown in Fig. 4 and Fig. 5, when calling any object fails, the call process that takes place is rolled back, and when the rollback fails, the exception message is recorded and retried, so that it can be guaranteed Data consistency across the system. At the same time, the use of the automatic retry mechanism also eliminates the need for human intervention, saves the input of manpower and material resources, and can also improve the efficiency of rollback processing.

In addition, in the embodiment of the present invention, a device for processing abnormal events is also provided. Referring to FIG. 6 , the abnormal event processing apparatus 600 may include: an abnormality detection unit 610 , an abnormality storage unit 620 , a retry unit 630 and a deletion unit 640 .

Wherein, the abnormal detection unit 610 is used to detect whether an abnormal event occurs during the execution of the business; the abnormal storage unit 620 is used to store the abnormal event corresponding to the abnormal event in the target database if the abnormal event is detected. message; the retry unit 630 is used to read the exception message stored in the target database, and retry the corresponding business according to the read exception message; the delete unit 640 is used to remove the Delete the exception message read from the database.

In some embodiments of the present invention, based on the foregoing solution, the abnormal event processing apparatus 600 further includes: a first recording unit configured to accumulate the number of retries corresponding to the read abnormal message when the retry fails.

Wherein, the retry unit 630 is configured to: read the abnormal message whose corresponding retry times are less than a predetermined number in the target database.

In some embodiments of the present invention, based on the foregoing solution, the retry unit 630 is configured to: regularly read the exception messages stored in the target database according to a predetermined period.

In some embodiments of the present invention, based on the foregoing solution, the abnormal event processing apparatus 600 further includes: an analyzing unit configured to analyze the abnormal event, so as to obtain an abnormal message corresponding to the abnormal event.

In some embodiments of the present invention, based on the foregoing solution, the abnormality detection unit 610 includes: a rollback unit, configured to call multiple objects sequentially in the same transaction, if the call to any object fails, the call that has occurred The process performs rollback processing; the determination unit is used to determine that an abnormal event of the rollback business is detected if the rollback failure of the calling process that has occurred is detected.

In some embodiments of the present invention, based on the foregoing solution, the exception storage unit 620 is configured to: store a message of rollback failure of the call process that has occurred in the target database.

In some embodiments of the present invention, based on the foregoing solution, the rollback unit is configured to: acquire a corresponding callback path according to the transaction identifier; call a callback method based on the callback path, and The resulting call is rolled back.

In some embodiments of the present invention, based on the foregoing solution, the abnormal event processing apparatus 600 further includes: a second recording unit, configured to record the transaction identifier when calling each of the plurality of objects and the corresponding callback path.

In some embodiments of the present invention, based on the foregoing solution, the second recording unit is configured to: when the rollback of the call process that has occurred is successfully rolled back, delete the transaction identifier and The corresponding callback path.

In some embodiments of the present invention, based on the foregoing solution, the second recording unit is configured to: delete all recorded information related to the transaction identifier when all the calls to the multiple objects are successful.

In some embodiments of the present invention, based on the foregoing solution, the abnormal event processing apparatus 600 further includes: a calling unit, configured to continue calling the next object in the plurality of objects according to the calling sequence when calling any object successfully objects until all the calls of the multiple objects are completed.

Since each functional module of the abnormal event processing apparatus 600 in the exemplary embodiment of the present invention corresponds to the steps in the above exemplary embodiment of the abnormal event processing method, details are not repeated here.

In an exemplary embodiment of the present invention, an electronic device capable of implementing the above method is also provided.

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

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

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

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

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

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

The units described in the embodiments of the present invention may be implemented by software or by hardware, and the described units may also be set in a processor. Wherein, the names of these units do not constitute a limitation of the unit itself under certain circumstances.

As another aspect, the present application also provides a computer-readable medium. The computer-readable medium may be included in the electronic device described in the above-mentioned embodiments; or it may exist independently without being assembled into the electronic device. middle. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by an electronic device, the electronic device is made to implement the method for processing abnormal events as described in the above-mentioned embodiments.

For example, the electronic device can implement as shown in Figure 1: step S110, during the execution of the service, detect whether an abnormal event occurs; step S120, if the abnormal event is detected, store the abnormal event in the target database The abnormal message corresponding to the abnormal event; step S130, read the abnormal message stored in the target database, and retry the corresponding business according to the read abnormal message; step S140, when the retry is successful, from The target database deletes the read exception message.

It should be noted that although several modules or units of an apparatus or apparatus for action execution are mentioned in the above detailed description, such division is not mandatory. Actually, according to the embodiment of the present invention, the features and functions of two or more modules or units described above may be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided to be embodied by a plurality of modules or units.

Through the description of the above implementations, those skilled in the art can easily understand that the example implementations described here can be implemented by software, or by combining software with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, and the software product can be stored in a non-volatile storage medium (which can be a CD-ROM, U disk, mobile hard disk, etc.) or on a network , including several instructions to make a computing device (which may be a personal computer, a server, a touch terminal, or a network device, etc.) execute the method according to the embodiment of the present invention.

Other embodiments of the invention will be readily apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present invention, these modifications, uses or adaptations follow the general principles of the present invention and include common knowledge or conventional technical means in the technical field not disclosed in the present invention . The specification and examples are to be considered exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It should be understood that the present invention is not limited to the precise constructions which have been described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims (15)

1. A kind of 1. processing method of anomalous event, it is characterised in that including：

   In the implementation procedure of business, detect whether anomalous event occur；

   There is the anomalous event if detecting, exception corresponding with the anomalous event is stored in target database and is disappeared Breath；

   The unexpected message stored in the target database is read, and weight carries out corresponding business according to the unexpected message of reading Examination is handled；

   When retrying successfully, the unexpected message of reading is deleted from the target database.
2. 2. the processing method of anomalous event according to claim 1, it is characterised in that in the unexpected message pair according to reading Corresponding business is carried out after retrying processing, is further included：When retrying unsuccessfully, the cumulative unexpected message that reads is corresponding to be retried time Number；

   Wherein, the unexpected message stored in the target database is read, including：Read corresponding heavy in the target database Try the unexpected message that number is less than pre-determined number.
3. 3. the processing method of anomalous event according to claim 1, it is characterised in that read in the target database and deposit The unexpected message of storage, including：

   According to predetermined period, the unexpected message stored in the target database is periodically read.
4. 4. the processing method of anomalous event according to claim 1, it is characterised in that storage and institute in target database Before stating the corresponding unexpected message of anomalous event, further include：

   The anomalous event is parsed, to obtain the corresponding unexpected message of the anomalous event.
5. 5. the processing method of anomalous event according to any one of claim 1 to 4, it is characterised in that in holding for business During row, detect whether anomalous event occur, including：

   When calling multiple objects successively in same affairs, if to any object malloc failure malloc, to the invoked procedure occurred Carry out rollback processing；

   Fail if detecting to the invoked procedure rollback occurred, it is determined that detect that anomalous event occurs in rollback business.
6. 6. the processing method of anomalous event according to claim 5, it is characterised in that storage and institute in target database The corresponding unexpected message of anomalous event is stated, including：

   The invoked procedure rollback failure to having occurred is stored in the target database.
7. 7. the processing method of anomalous event according to claim 5, it is characterised in that carried out to the invoked procedure occurred Rollback is handled, including：

   According to the mark of the affairs, corresponding readjustment path is obtained；

   Callback method is called based on the readjustment path, and rollback is carried out to the invoked procedure occurred according to the callback method Processing.
8. 8. the processing method of anomalous event according to claim 7, it is characterised in that in the multiple object is called During each object, the mark of the affairs and corresponding readjustment path are recorded.
9. 9. the processing method of anomalous event according to claim 8, it is characterised in that record the affairs mark and After corresponding readjustment path, further include：

   If detecting to the invoked procedure rollback success occurred, recorded when deleting the calling any object described The mark of affairs and corresponding readjustment path.
10. 10. the processing method of anomalous event according to claim 8, it is characterised in that recording the mark of the affairs After corresponding readjustment path, further include：

    If calling success to the multiple object, deletion record with the relevant all information of the mark of the affairs.
11. 11. the processing method of anomalous event according to claim 5, it is characterised in that further include：

    If being called to any object successfully, continue to call next object in the multiple object according to calling order, directly All call and complete to the multiple object.
12. 12. the processing method of anomalous event according to claim 5, it is characterised in that the multiple destination object is point Node in cloth system.
13. A kind of 13. processing unit of anomalous event, it is characterised in that including：

    Abnormality detecting unit, in the implementation procedure of business, detecting whether anomalous event occur；

    Abnormal memory cell, if there is the anomalous event for detecting, storage and the exception in target database The corresponding unexpected message of event；

    Unit is retried, for reading the unexpected message stored in the target database, and according to the unexpected message of reading to phase The business answered carries out retrying processing；

    Unit is deleted, for deleting the unexpected message of reading from the target database when retrying successfully.
14. 14. a kind of electronic equipment, it is characterised in that including：

    Processor；And

    Memory, is stored with computer-readable instruction on the memory, the computer-readable instruction is held by the processor The processing method of the anomalous event as any one of claim 1 to 12 is realized during row.
15. 15. a kind of computer-readable recording medium, is stored thereon with computer program, the computer program is executed by processor The processing method of anomalous events of the Shi Shixian as any one of claim 1 to 12.